Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 081 / opus100c.arc / O_SYSDOC.ARC / OPUSDOC.TXT

Wrap

Text File | 1987-07-13 | 316.8 KB | 9,241 lines

OOOOOOOOOOOOOO OOOOOOOOOOOOOO OOOOOO OOOOOO OOOOOOOOOOOOOO OOOOOOOOOOOOOO OOOOOOOOOOOOOO OOOOOO OOOOOO OO OOOOOOOOOO OO OO OO OO OO OO OO OO OO OO OO OOOOOO OO OO OOOOOO OO OO OO OO OO OO OO OO OOOOOO OO OO OOOOOO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OOOOOOOOOO OO OO OO OO OO OOOOOOOOOO OO OO OO OO OOOOOOOOOO OO OO OOOOOO OO OO OOOOOOOOOO OO OOOOOO OO OO OO OO OOOOOO OO OO OO OO OOOOOO OO OO OO OO OO OO OO OO OO OO OO OOOOOOOOOOOOOO OOOOOO OOOOOOOOOOOOOO OO OO OOOOOOOOOOOOOO OOOOOO OOOOOOOOOOOOOO OO OO OO OO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OO oMMM OO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO Computer-Based Conversation System Version 1.0 June 14, 1987 Documentation for System Operators Copyright 1986, 1987. Wynn Wagner III. All rights reserved. Editor's note: The documentation that follows is "shareware" of a subtly different sort: it's the product of a host of volunteers, chief among whom is Wynn Wagner. First-party references are Wynn speaking. Even though 1.0 is a "release" version of Opus, we consider the documentation to be still in "Beta" form. It was pulled together from many sources, and you're going to find some duplication as well as omissions. In all likelihood, you'll also find some semi-bizarre formatting glitches. Your indulgence is appreciated. We'd planned a complete index for the release of Opus 1.0, but as the deadline approached, it became clear that our reach exceeded our grasp. Or something like that. Rather than release an index that's half-baked, we thought we'd wait and send it out after Opus hits the streets. Please send suggestions, corrections, observations, wishes, etc. to 133/12 (route via 133/1). All input will be gratefully received. Happy computing, John Miller ii Table of Contents INTRODUCTION ........................................ 1 Howdy ........................................... 1 Guarantee ....................................... 1 Notices and such ................................ 2 Using Opus ...................................... 2 Lawful and Friendly ......................... 2 Non-governmental ............................ 2 Governmental ................................ 2 Distributing Opus Software ...................... 2 Payment ..................................... 3 Credit and Gratitude ............................ 3 Miscellaneous ................................... 5 OPUS OVERVIEW ....................................... 6 What it is ...................................... 6 What's new in Opus 1.0 .......................... 6 Opus now sends mail ......................... 6 Built-in echomail scanner. .................. 6 Built-in anti-duper ......................... 8 Required Hardware ............................... 13 Software ........................................ 14 Messages ........................................ 15 Local ....................................... 15 Matrix ...................................... 15 Broadcast ................................... 15 File Transfers .................................. 15 Uploads ..................................... 16 Downloads ................................... 16 Matrix ...................................... 16 Operating Philosophy ............................ 16 The difference between Opus and Fido<tm> ........ 16 Extended Display File Capability ................ 17 Extended File Transfer Protocols ................ 17 EchoMail Enhancements ........................... 17 Mail Interface .................................. 18 Extended Message Area Attributes ................ 18 Private only ................................ 18 Public only ................................. 18 EchoMail .................................... 18 Matrix messages ............................. 19 Barricaded .................................. 19 iii Message Area Commands ........................... 19 R)ead message menu. ......................... 19 F)orward .................................... 19 H)url ....................................... 19 =)Read non-Stop ............................. 19 S)can ....................................... 19 O)utside message maintenance ................ 20 X)port to disks ............................. 20 U)pload message .............................. 20 File Area Commands .............................. 20 H)url ........................................ 20 O)utside File Maintenance ....................... 20 Miscellaneous Commands .......................... 20 INSTALLATION ........................................ 23 Equipment ....................................... 23 Files ........................................... 24 CONFIG.SYS .................................. 24 FILES=xx ................................ 24 BUFFERS=xx .............................. 24 COUNTRY=xxx ............................. 25 DEVICE=ANSI.SYS ......................... 25 STACKS=n,s .............................. 26 AUTOEXEC.BAT .................................... 26 FOSSIL ...................................... 26 Set TZ= ..................................... 27 Subdirectories .............................. 28 Things that can go wrong ........................ 30 Opus-CBCS From The Inside ....................... 31 SETUP ............................................... 34 How to set up a new message area ................ 34 Message area maintenance ........................ 36 How to set up a new file area ................... 36 File area maintenance ........................... 37 THE MATRIX .......................................... 38 Netmail for the complete novice ................. 39 Introduction ................................ 39 An overview of node-to-node mail ............ 41 The incoming message bundle ................. 42 The outgoing mail bundle .................... 43 Quick start to netmail ...................... 43 The node list ............................... 45 The BBS.CTL file ............................ 45 iv Matrix overview for the grizzled ................ 49 A new way of thinking about mail ............ 49 Idea #1 ................................. 49 Idea #2 ................................. 49 Idea #3 ................................. 50 File names ...................................... 50 Bundle names ................................ 50 Flow file names ............................. 51 Archived messages ........................... 51 How it all works ............................ 52 Enter Opus, stage right ..................... 52 Z-Event ..................................... 53 The behavior window ..................... 53 Z-Event overview ........................ 54 How to set up Opus to receive Matrix traffic .... 54 The national mail hour ...................... 57 Overnight long distance ..................... 58 Daytime local-only .......................... 58 How to get into the Matrix ...................... 58 Matrix structure ............................ 59 Matrix addresses ............................ 60 Your area ................................... 60 Asking for a number ......................... 61 Getting along ............................... 61 Operating (in) the Matrix ....................... 62 Matrix hold area ............................ 62 Outbound Matrix traffic ..................... 62 The Matrix UNschedule ....................... 63 Matrix bundlings ............................ 64 Matrix File Requests ............................ 64 Approval listing ............................ 65 Matrix okfile ............................... 65 System advertisement and file list .......... 66 Implementation restriction .................. 66 Errors ...................................... 66 No such file ............................ 66 Initiating "bark" type file requests. ....... 67 Special Matrix menu ......................... 67 Unsuccessful connections .................... 68 Wild Echomail ............................... 69 New Matrix behavior mask .................... 69 Matrix session scripts .......................... 69 Contents of a script file ................... 70 Keywords .................................... 70 Checklist ................................... 73 Sample script ............................... 73 Matrix-oriented batch files ..................... 74 Sample batch file ........................... 75 Checklist for goin' online ...................... 76 v oMMM ................................................ 77 Quick Review of the Matrix ...................... 78 Outbound hold area .............................. 79 Methods ......................................... 79 What's in the holding area ...................... 80 Simple oMMM ..................................... 81 Routing in a nutshell - ......................... 82 Flavors of routing .............................. 82 The control file .................................... 85 Contents ........................................ 86 Do what I say, when I say it .................... 86 Special words ................................... 86 Using oMMM .......................................... 87 Operational overview ............................ 87 Switches .................................... 87 Schedule tag ................................ 88 Info path ................................... 88 Hold path ................................... 88 Message path ................................ 88 Pre-message scan control file ............... 89 Control file ................................ 90 Reference stuff ................................. 90 File names .................................. 90 What about Opus? ............................ 90 ECHOMAIL ............................................ 92 Getting started with Echomail ................... 92 Scan control file ........................... 93 Method ...................................... 93 The Meadow ...................................... 94 Other areas ..................................... 95 Routing and coordination ........................ 96 How it started .................................. 97 OPERATING OPUS ...................................... 99 The Sysop section ............................... 99 Area maintenance ............................ 99 Priv. required .............................. 100 Kinds of messages ........................... 100 Message Types ........................... 100 Message Editing ......................... 100 Miscellaneous ........................... 101 BBS Menu path and barricade file ............ 101 Message path ............................ 102 Help path ............................... 102 Download path ........................... 102 Upload path ............................. 103 Titles .................................. 103 Another area ............................ 103 Quit .................................... 104 vi Matrix ...................................... 104 Information ............................. 104 Poll .................................... 105 Unpack .................................. 105 Clear undialables ....................... 105 Quit .................................... 106 Events and behavior windows ................. 106 List .................................... 106 Change .................................. 107 Status .................................. 107 Kind .................................... 107 Day ..................................... 108 Time .................................... 108 Zone .................................... 108 Length .................................. 108 Forced .................................. 109 Exit code ............................... 109 Bell duration ........................... 110 Z-Event ................................. 110 Housecleaning ....................... 110 Z-Event ................................. 110 Matrix behavior window .............. 110 Quit .................................... 111 Privs/Menus ................................. 112 Outside ..................................... 113 Embedded Commands ................................... 113 The basics ...................................... 114 Data display .................................... 115 Questionnaires, surveys, order forms ............ 116 Flow and user interaction ....................... 116 Privilege control ............................... 117 FILES.BBS Commands .............................. 118 Questionnaire commands ......................... 118 Example 1 ................................... 119 Example 2 ................................... 120 For more information on Opus ........................ 122 Appendix A - Cyberpunk? ............................. 124 Appendix B - Opus and support file list vii Appendix C - Miscellaneous reference stuff .......... 129 Multitasker notes ............................... 129 DoubleDOS ................................... 129 Modem notes ..................................... 130 USR Courier ................................. 130 Telebit Trailblazer ......................... 130 Hayes V-Series .............................. 132 viii INTRODUCTION Howdy! Welcome to Opus, the computer-based conversation system. This system falls into a new area of software: Militantly Public Domain. There is a copyright and limited license. Its sole purpose is to ensure Opus remains available for no money. +----------------------------------------+ | | | Free? Does this mean I can't | | get a discount? | | | | Nunzio | | Opus By-Laws & | | Covert Action Committee | | | +----------------------------------------+ Because no money is charged, Opus sysops aren't consumers. It's more like a community effort. +----------------------------------------+ | | | Be sure you keep Opus free. | | | | Opus never was free. Just because | | there's no money charged doesn't | | mean it's free. The LAWFUL AND | | FRIENDLY license can be more | | expensive than money. | | | | --- from a conversation | | | +----------------------------------------+ Guarantee: You've got to be kidding. Opus-CBCS carries only one guarantee: if you break it, you own both parts. To put it another way, if you run Opus, you do so entirely at your own risk. Opus CBCS 1.0 -1- Introduction to Opus The system may or may not work under your particular circumstances. If it does work, it is possible somebody will invent a way to destroy everything on your disk. Opus contains lots of security features, but those features don't come with any sort of guarantee. As far as a warranty or guarantee is concerned, you are as thoroughly on your own as you can possibly be. More so, probably. Notices and such The Opus Computer-Based Conversation System and all supporting materials are copyrighted by Wynn Wagner III. All rights are reserved. Using Opus Lawful and Friendly are the important words. The author of this system takes the license quite seriously, and if you use Opus you have to do so in a lawful and friendly manner. Non-governmental: You are given a limited license to use Opus-CBCS as long as you do so in a lawful and friendly manner. This includes commercial installations. There is no money involved in running an Opus system. Governmental: Groups controlled or supervised by any government must contact OPUSinfo Here before putting an Opus sysop on-line. There is a license fee for governmental use. Distributing Opus Software You are given permission to distribute Opus-CBCS and its support files for non-governmental use as long as there is no money charged. Nobody is ever to make money from the distribution of Opus software. If your system is a bulletin board, you may not keep Opus on line for download if you charge money to your callers. Opus CBCS 1.0 -2- Introduction to Opus If your system is a time-share system, you must arrange in advance to donate any connect charges to The Shanti Project. Payment: In those cases where money must change hands, a $50.00 payment to The Shanti Project of San Francisco is required for each copy of Opus that is put on line SUBTLE CHANGE FROM PREVIOUS VERSIONS: Opus 0.00 said nobody was to make money from "suggesting its use." That was for consultants. That wording has been dropped because it was confusing. There is no longer any payment required for consultants or for those who suggest Opus to employers or clients--as long as there is no charge for the software itself. Credit and Gratitude Nobody who worked around the Opus 1.00 crew would dispute that the following folks have gone out of their way to help the project. We'll call this "Opus: Sine Qua Non" (the list of folks, without whom there would be no Opus).... DAVID FINSTER The original alpha tester, and the sysop of OPUSinfo Here. If there's something that a hacker is unable to do on your board, it is probably because David's sneaky mind thought of it first and showed me how to break the system. BOB HARTMAN In addition to tweaking my sealink file transfer routine until it had a reasonable disposition, Bob adopted my source to the oMMM program. He chipped in to help code when he saw the need. He is also the author of Opus!Comm (the first-ever FOSSIL program) and a series of echomail utilities. Opus CBCS 1.0 -3- Introduction to Opus RICK HUEBNER He sent code! Here are some of the modules that Rick wrote: OOMP (the internal scanner), ZModem, and dialing scripts. Rick would make the mistake of telling me something like "I'm going to get bored this weekend. Got anything that needs to be written?" Not being the type to pass up many of those kinds of offers, I'd have a design doc headed his way in short order! Rick really does nice work... although it's chock full of tacky squiggles. In fact, I would swear Rick is guilty of gratuitous squiggling. MIKE KELLEHER Mike is currently taking a sabbatical from his work as the sysop of OPUSinfo There. We'll call him OPUSinfo Emeritus. Over the past several months, he's helped hundreds of sysops while maintaining a strong sense of The Hobbyist Spirit. JOHN MILLER Documentation editor. I'm thanking John before I've even read the documentation. He's pulling the docs together as I'm writing this [please excuse Wynn's jerky handwriting- -Ed.]. So... what I'll thank him for now is this: the chutzpah to jump in with both feet at the 11th hour. VINCE PERRIELLO The other alpha tester. Vince is also one of the prime instigators (read "nag") of the FOSSIL standard. The Opus beta-test team included: Rob Elliott Chuck Lawson Mike Kelleher Harv Neghila Jon Sabol Butch Walker Henk Wevers Opus CBCS 1.0 -4- Introduction to Opus In addition to the active participants, the following should be mentioned for doing things without which we would have no Opus: Ward Christiansen. thought up both XModem and bulletin boards Tom Jennings. originated the e-mail network now known as FidoNet<tm> Chuck Forsberg. designed ZModem, the fastest and most reliable file transfer protocol available Miscellaneous Fido and FidoNet are trademarks of Tom Jennings. The Sealink file transfer method is copyrighted by System Enhancements Associates. They have released the protocol for general use in return for this notice. The word "opus" is Latin for "project." Although several Opus system operators have adopted a certain penguin as a mascot, you should know that this is not official. Opus-CBCS software has nothing to do with the comic strip Bloom County that has a character named Opus. Any matters involving copyrights and/or trademarks on the penguin are between you and The Washington Post Co. (Bloom County did win a Pulitzer this year... maybe we should.... naw....... ) Opus CBCS 1.0 -5- Introduction to Opus OPUS OVERVIEW What it is: Opus is an evolving computer-based conversation system that combines simplicity with configurability. Simplicity, in that a novice can have a rather nice bulletin board up and running very quickly. Configurability, in that an advanced sysop can turn the customization of his or her board into an art form. It's entirely up to you! Therein lies Opus's charm: it has all the power an advanced sysop demands, while still being easy for both the user and the system operator. Opus provides a feature-rich electronic messaging system, wide choice of file upload and download protocols, plus access to the world's premier amateur e-mail network. Clearly, it would be a bargain at twice the price! What's new in Opus 1.0: Opus now sends mail Version 0.0 of Opus relied on some kind of external<tm> program for sending mail. It could receive O.K., but hadn't learned to send for itself yet. That's all been taken care of in version 1.0, and Opus is now a complete standalone electronic mail package. Built-in echomail scanner. Opus 1.0 has an internal scanner; however, there is no intention for it to be a total replacement for programs such as FastScan or ScanMail. Those standalone programs are more "robust" and can handle more complicated situations. The built-in scan feature makes some assumptions: * No message is longer than 12,000 bytes * No area is echo'd to more than 10 systems A non-scientific survey shows that many (but not all) systems will be able to use the built-in scan feature. Opus CBCS 1.0 -6- Opus Overview If you can live with those restrictions, you can use the built-in scan feature. If not, you need to use one of the larger stand- alone systems. The reason for the restrictions is this: if we can make those assumptions, we can have a lightening-fast scanner that will fit into memory at the same time as Opus. We can use a totally new way of scanning messages that lowers the overhead greatly. Without the limitations mentioned above, the scan routine would have to be larger and slower. The original design (or text-based flow chart) was done by Wynn Wagner. The scanner was written by RICK HUEBNER. Opus CBCS 1.0 -7- Opus Overview Built-in anti-duper If you use Opus's internal scanner, you will also benefit from a new internal Echomail dupe detector/preventer. Not a dupe killer, it simply doesn't toss duplicate messages in the first place. At least, that's the theory! Matrix attributes, assumptions and options Several new assumptions and options have been added concerning Opus message attributes. A minimum privilege level can be assigned to each option. See OPUS.CTL for details. Forward, then kill The FK command lets you forward a message, then kill the original. External file transfer programs Opus 1.0 has more flexibility for external file transfer protocols. Ten "slots" are available for file transfer protocol programs. "Sysop is next" key When a caller is on-line, the "S" key toggles a flag that tells Opus not to let any more callers on-line. In other words, Opus will hold the system for you. Internal video codes New embedded codes let you specify color attributes within a .BBS file. That means a single file can replace the former .BBS/.GBS combination. The old method is still supported. Orphan command This command has been eliminated in the Files area External file management option You can link an external file manager directly into the File area menu. Opus CBCS 1.0 -8- Opus Overview Carrier loss handling Opus can now perform its own "watchdog" and reboot after carrier loss when an external program is invoked. Video method The local console video output method may be optimized for certain computer types. LAN support OPUS.EXE can now be kept on a server External message management You may link an external message manager directly into the Message area menu. Zone command This command is no longer supported in the message area menu. .CTL/.PRM check Opus makes a big fuss (but keeps on truckin') if there is a date/time mismatch suggesting you may have forgotten to re- assemble a control file after you make some changes. Time and date display format flexibility You can control how dates and times are displayed in messages. Time and date storage format There has been a change in the internal date/time format of message files (*.MSG). Opus CBCS 1.0 -9- Opus Overview Expanded multitasker support In addition to DoubleDOS, Opus now supports several other operating system enhancement programs. DOS gateway You can execute a DOS command from the local sysop menu when Opus is waiting for a caller. Task numbers Opus now lets you specify a task number, thus making it easier to run multiple copies of Opus on the same PC. This will affect the names of certain files. No chat during .GBS/.BBS file execution Because of the overlay structure, you cannot go into chat when any .GBS/.BBS file is executing. Opus sends a warning to the local console if you try it. Forced events Events may be declared as forced. A forced event which gets overrun by a mail transfer will be executed retroactively. Messages from disk files Opus can create a message from a text file. Disk space alarm If disk space gets low in the primary areas for netmail, Opus raises a ruckus. Multiple Matrix addresses You may declare up to 15 Matrix addresses. Only the first address will be associated with outbound traffic. This is especially handy for hosts and hubs. Opus CBCS 1.0 -10- Opus Overview Uploaded messages Users may upload messages. External message editor An external message editor may be declared in place of the normal line-oriented editor. Opus will automatically quote any message to which you reply with an external editor. New embedded command GoTo permits jumping over a section of .GBS/.BBS files. Asynch ports You may specify up to 16 asynch ports, provided your FOSSIL program supports them. Keyboard commands The "K" key replaces ^K for local keyboard command. "M" replaces ^U, and calls a Matrix menu for performing several Matrix operations. FILES.BBS wildcards Files may be listed with wildcards in FILES.BBS, and become available for downloading. Event manager supports day-of-week Events can now run on a single day of the week. Outside embedded command supports parameters The ^OC command now supports parameter passing for use by external programs. Internal ZMODEM protocol This fast, robust protocol is supported as an internal file transfer protocol as well as for netmail (with another Opus 1.0) Opus CBCS 1.0 -11- Opus Overview New netmail handshake Opus uses The YooHoo(c) handshake protocol. It is compatible with most other non-Opus netmail systems. Zone and point addressing These extensions to the NET/NODE addressing scheme will support INTERNATIONAL as well as LOCAL mail addressing. Extra support for external Echomail programs Optionally, Opus can create a log of message areas to which it tosses Echomail. This will let external programs process only those areas that have changed. Extended modem support Higher baud rates, as well as a "locked" serial port speed are supported for compatibility with new high-speed modems. Several forms of flow control are also supported Lastread pointers for Sysop The lastread pointers for the first user in the USER file are retained for all areas, not just the eight allowed for regular users. Also, the lastread pointers are the same for local keyboard mode as well as remote access mode. Default of user to area one on carrier loss If carrier is dropped, the user record is set to area one if the caller was in a message or file area over 50. C)ontents command displays date and time The C)ontents command in the file area will display the date/time of each file in an archive. Logon time limit You may specify your own logon time limit for users. Opus CBCS 1.0 -12- Opus Overview Configurable "looking busy" support You may specify the string which makes your modem look busy, including DTR manipulation. Dialing script support You may write a dialing script and specify it in place of a phone number in your node list. This is useful for accessing certain networks. Export message to disk Messages may be written to disk in ASCII format by selecting the X)port command from the Message area menu. Enhanced embedded user input command accepts the <enter> key Questions, or menus with embedded commands, can now accept the <enter> key as a valid reponse. Required Hardware Standard equipment for Opus consists of: AT-class computer with Award BIOS 72-Meg hard drive One each: TeleBit Trailblazer modem (9600 bps) U.S.Robotics HST modem (9600 bps) Amdek 722 EGA monitor PC DOS 3.3 Mirror sunglasses Nerf bat That roughly describes Wynn's computer setup. It is the only one that carries any sort of assurances. It is: -={ Opus will sometimes run on Wynn's computer }=- No other assurances are made. All other equipment is officially classified as Non-Standard. Opus CBCS 1.0 -13- Opus Overview In general, you have a reasonable chance of getting Opus 1.0 to work on any MS-DOS computer with at least 128k of available memory. In most cases, you will want to be able to run external programs from Opus, and that requires a minimum of 256k. Hardware incompatibilities are resolved through a special program called FOSSIL. It contains modem, keyboard and video methods for specific hardware configurations. It means the same version of Opus can run on an IBM PC, an IBM PS/2, a DEC Rainbow or a Tandy 2K. The only difference is the FOSSIL program. Theoretically, Opus will use any modem that uses the Hayes command set and supports DTR. It has been successfully tested with the USR Courier and the Hayes family (2400 and down). If you use another modem type, Opus should work (but see guarantee, p. XX). In the OPUS.CTL file, initialization strings for several models of modems are listed. If you get other brands of modems to work with Opus, please contact one of the INFOnodes and let them know the brand name, the initialization string and what you did to get it to work. Also, Opus REQUIRES a storage device larger than a floppy drive. Generally, this will be a hard drive, but could just as easily be cartridge media such as a Bernoulli Box. There are absolutely no plans to release a version that will run on floppies; the support files simply take too much room. Software Several pieces of software are required to make Opus work. A couple are worth singling out. First, DOS 2.1 or higher...2.0 and below are NOT supported. In fact, not all of Opus's features will work under DOS 2.1. DOS 3.1 or higher is recommended for a fully-featured Opus system. There are no guarantees that DOS 2.1 will be supported in future releases of Opus. Next, FOSSIL. This is where Opus's low-level communications routines live. FOSSIL is a memory-resident assembly language program or device driver designed especially for Opus. It supplies the routines Opus needs to communicate with the modem. If you are running other memory-resident programs, you may experience difficulty with FOSSIL. Installing FOSSIL last may solve the problem, but it is NOT guaranteed. Opus CBCS 1.0 -14- Opus Overview Messages Messages can be of three basic types, or scopes: local, Matrix and broadcast. A message's scope determines its behavior on an Opus-based system. Local Messages Local messages are the simplest form available, common to almost all BBS systems. Local messages are available to a predefined group of users on a single BBS--the one where they were entered. Matrix Messages Matrix is the Opus word for network. This was chosen because of the ambiguity associated with the word "network." The Matrix is defined as a group of bulletin boards with can exchange information via the telephone network. Opus 1.0 can place outgoing Matrix calls, and receive incoming mail from other Opera, or other systems running either the FidoNet<tm> or WaZOO matrix protocols. Broadcast Messages Broadcast messages are fully compatible with EchoMail, which is covered in more detail later in this manual. EchoMail, by Jeff Rush, provides a means of maintaining the same message base on multiple bulletin boards. This allows conferencing--even internationally--if you choose to do so. Remember, phone calls placed for mail transfers cost the same as regular calls. Be aware that anything involving Matrix transactions can involve long distance phone charges. File Transfers Opus supports three different types of file transfers: uploads, downloads and Matrix. These enable sharing of public domain or "shareware" software among users and other bulletin board systems. Opus CBCS 1.0 -15- Opus Overview Uploads Uploading is defined as a user sending a file TO a BBS. This lets users share programs they have written or collected. Downloads Downloading is defined as a user receiving a file FROM a bulletin board system. This allows a single point to serve as a 'holding tank' for software that can be freely shared among users. Matrix Matrix transfers are uploads or downloads between two Matrix systems. You can direct Opus to send a file to any other system in the Matrix. Opus will accept incoming Matrix files any time it is not busy. Operating Philosophy The operational philosophy of Opus can be summed up in a very brief statement: -={ KEEP IT SIMPLE! }=- Opus is very easy to use if you let the installation kit do its job. A sysop can lead a very satisfying life with the basic Opus installation. It will still be a superior system, requiring a minimum of maintenance. There are thousands of custom features available; each Opus board will probably look and act differently, but there is no guarantee that any of the customization methods will be easy or immediately apparent. It's best to start with a basic system and to customize things gradually after gaining experience with Opus. The difficult functions are always available, but never required. If you want to tailor your system to look and act a certain way, you can, any time. The rewards you reap are proportional to the amount of work you put into the system, and that can run into years if you let it. Opus CBCS 1.0 -16- Opus Overview The difference between Opus and Fido<tm>: Opus is an evolutionary step in the field of networked bulletin boards pioneered by Tom Jennings and Fido. Opus isn't a Fido<tm> "clone;" the only compatibility between Opus and Fido<tm> involves the structure of the support files--such things as Dir.Bbs, Welcome1.Bbs, etc., and data files like User.Bbs. Extended Display File Capability ANSI graphics are supported as a user option. Each support file has two flavors: Text and Graphics. These are differentiated by extension; text files have an extension of .BBS, and graphic files, .GBS. Through the use of an embedded command, you can make any support file branch to an external program. The sysop is responsible for insuring that the program directs its output to the comm port. This feature allows multiple "Outside" features to be supported. Questionnaire information can be collected from within any BBS/GBS file. This can be used to log the activity of any displayed section of your board. You can insert a person's name, display a quote, date and time, etc., within any BBS/GBS file. Virtually anything Opus knows about the user can be displayed at any point in the support files. Additional embedded commands allow you to make any BBS/GBS file a submenu. This is handy for things like multiple bulletins, interactive help systems, etc. A complete treatment of embedded commands begins on Page 104. Extended File Transfer Protocols Several transfer protocols are supported in Opus. These include Zmodem, Ymodem, Xmodem, Telink, and SEALink. Opus also has ten "slots" available for installation of external protocols, at the sysop's discretion--for example, Windowed Xmodem (WXmodem), Sliding Window Kermit and MNP. These will be described more thoroughly in the file transfer section. EchoMail Enhancements Opus lets the sysop determine whether EchoMail SEEN-BY lines are displayed to the user. Few appreciate the unsightliness of this part of EchoMail, and Opus eliminates that problem. If you do not care for SEEN-BYs, Opus lets you disable their display. Opus CBCS 1.0 -17- Opus Overview The display of extended addressing can be disabled. As more distinct addresses become available over the Matrix, more information will need to be embedded within the body of messages. Opus lets you control who can and can't see this information. Opus automatically inserts its own origin line if a message area is marked as broadcast. This lets other systems know what package processed the mail. You can tell Opus to unARC and toss ArcMail and EchoMail packets automatically. You no longer have to declare an external event to extract ArcMail packets and toss EchoMail--Opus does this for you. Mail Interface Opus can receive mail bundles anytime. In other words, Matrix transactions are not restricted to fixed time slots. You can also SEND send mail to another Opus anytime. Opus messages are completely compatible with FidoNet<tm> specifications as defined in documents published by the FidoNet Technical Standards Committee at the time Opus 1.00 was released. Extended Message Area Attributes A variety of message area attributes are supported. With them, you can define exactly what type of messages will be placed in what area. Private only: All messages entered in this area will be marked "private," and cannot be read by other users. Public only: All messages in this areas can be read by all users. Read-only: Messages in this area can be read by callers, but only sysops and assistant sysops can enter new messages. Anonymous messages: In an area marked as "anonymous," Opus will ask the user to supply a pseudonym. EchoMail Conference-type message bases are recognized. The user will be told that the message will be broadcast, and Opus will automatically do such echomail-oriented processing as inserting an "origin line" into the message. Opus CBCS 1.0 -18- Opus Overview Matrix messages These are treated like FidoNet<tm> messages. The user is asked where the message is to be sent and to whom. Barricaded: Barricade areas have passwords associated with them; by using this feature, you can allow people higher privileges within certain areas. These attributes may be combined in any fashion. You can require all messages in your Matrix area to be private, or all EchoMail messages to be public. It is totally up to the sysop as to how message areas will behave. Message Area Commands Opus does not have a separate R)ead message menu. All the message commands are contained in one menu, making message functions much easier to manage. Following is a brief description of Opus's file and message commands, including some enhanced functions: F)orward Lets you copy a message to another user. This comes in handy when a user has entered a message to the wrong person. F)orward has another variation called Forward as Bombing Run. This lets you send a message to a list without having to reenter the message. H)url Can be used to move a message from one area to another. It's helpful for cleaning up behind users who don't understand the system. It's also handy for removing advertisements from EchoMail areas. (Note that using H)url requires the source and destination message areas to be located on the same physical drive.) =)Read non-Stop Just what it says. It will display messages continuously until the highest message is reached. By opening a capture buffer, the user may download an entire group of messages for reading offline. S)can Will check for messages to the user in ALL message areas. Opus CBCS 1.0 -19- Opus Overview Message area commands new with version 1.0 include: O)utside message maintenance Lets you call an external program for message maintenance chores. X)port to disks Turns a message into a disk file U)pload message Turns a disk file into a message Access to Opus's message editor commands is defined by a menu file. It works like any other "*PRIV.BBS" file and lets the system operator set access levels for the various commands. The LORE (line-oriented editor) has an additional command, H)andling, which lets you change message attributes. Current attributes include Private, Kill/Sent, File-Attach, Crash, File- Request, Return-Receipt Request, Update-Request, and Audit- Request. Some of these are for use with external mail programs, and have no real use when sending mail to another Opus system. File Area Commands New file area commands include: H)url This works for files just like it does for messages. O)utside File Maintenance Lets you call an external program for file maintenance activities. Miscellaneous Commands The user does not need to hit the return key at connect time to establish a baud rate. Opus does this automatically. ARC and LBR file contents can be displayed. The user can see what files are contained in an archive without downloading it. When a private local message is entered, Opus checks to see that a user by that name exists on the system. This insures that every message is deliverable. This function is disabled in Matrix and EchoMail areas. Opus CBCS 1.0 -20- Opus Overview All of the sysop commands are menu driven in Opus, making board maintenance much easier. The sysop can raise or lower an online user's time and or access privilege from the local console. Opus CBCS 1.0 -21- Opus Overview MMMMMM MM MM MMMMM MMMMMMMM MMMMMM MMMM MMMM MM MM MM MM M M MM M MMM MMM MM MM MM MMM MM MM MM MM MM MM MM MM MMMM MM MM MM MM MM MM MM MM MM MM MM MMMMM MM MMMMMMMM MM MM MM MM MMMM MM MM MM MM MM MM MM MM MMM MM MM MM MM MM MM MM MM MM M MM MM MM MM MM M MM M MMMMMM MMM MM MMMMM MMMM MMMM MMMM MMMMMM MMMMMM Installation of Opus-CBCS, v1 Opus CBCS 1.0 -22- Opus Installation INSTALLATION If you are upgrading an existing Opus, you may wish to jump directly to: QUIK_KIT.ARC Please address any comments about this installation procedure to: David Finster Matrix - 1:124/111.0 Data - (214) 991-3381 2400 BPS +-------------------------------------------------+ | | | "It's a hundred and six miles to Chicago. | | We've got a full tank of gas, half a pack | | of cigarettes, it's dark, and we're wearing | | sunglasses." | | | | "Hit it." | | ---- The Blues Brothers | | | +-------------------------------------------------+ Here's the theory: getting Opus running "out of the box" is supposed to be a fairly simple job. There are thousands of things you can do to Opus-CBCS to customize it, but none of that is guaranteed to be simple or straightforward. Even if you are an experienced sysop, please FIRST install Opus "by the numbers," and defer customizing and tweaking until after you have the system running. That way, you will keep the number of possible errors to a minimum. This installation assumes the following: * You are putting your system onto drive C: * You have a working knowledge of MS-DOS or PC-DOS * You are wearing mirror shades Opus CBCS 1.0 -23- Opus Installation Installation "by the numbers" . . . What you need to have on hand before you start: Equipment: Nerf bat IBM personal computer or close compatible with hard disk Files CONFIG.SYS File Config.sys lets you set some of the operating parameters of your computer at boot time. There are four-and-a-half (depends on your DOS version) commands that directly affect Opus' performance: FILES=xx This statement tells DOS how many files a single process may have open at one time. If a program tries to use more files than you have declared, it generally does nasty things, like deleting the currently opened files to make room for new ones. Not a pretty sight. Opus requires at least 20 files. DOS allocates 48 bytes for each file defined in Config.sys, So you can be pretty liberal in allocating these. If you are running some sort of multi-tasker, remember that your file handles are divided by the number of tasks running. That is, if you are running two programs, and you have files set to 20, each task will be allowed to open 10. This will not work with Opus. You will need to increase the number of files. The maximum number of file handles you can allocate is 255, but this is VERY excessive. BUFFERS=xx This tells DOS how much information to read in at a time when a transfer is made from disk to memory. Each buffer takes 528 bytes, so you might need to watch this if you are running in a limited amount of space. Generally speaking, if you specify too few buffers at boot time, you will slow the system down. If you specify too many buffers, you will slow the system down, so you really need to experiment with this one. We've found that between 40 and 60 is about right on most systems. The largest number of buffers that can be allocated under versions of DOS prior to 3.3 is 99. Opus CBCS 1.0 -24- Opus Installation COUNTRY=xxx This parameter specifies how the keyboard mapping, the currency symbol, the decimal separator, and most important, the date and time formats. OPUS WILL DO NASTY THINGS IF THE DATE FORMAT IS NOT 'MERICAN!!! You can still load an optional keyboard driver, but you must not specify a country code other than 001. If you have dates showing up as garbage, you have your machine installed for the wrong country, even if you happen to live there. DEVICE=ANSI.SYS You must include this statement in your Config.sys file to use Opus's graphics capabilities. ANSI enables computer-to- computer color and cursor positioning. SEE HERE: If there are a lot of numbers, semi-colons and left brackets on your screen when Opus runs, you do not have ANSI installed! You should install the ANSI device driver that comes with DOS (built into DEC's version) until your Opus is stable. Substitute video drivers may or may not work. +----------------------------------------------------------+ | | | Quick DOS lesson: You install ANSI by adding a | | line in CONFIG.SYS that reads: | | | | device=[fully-qualified pathname]ANSI.SYS. | | | | (Re)booting the machine will install ANSI.SYS, | | thus enabling Opus's graphics. | | | +----------------------------------------------------------+ For further information on setting up a CONFIG.sys file, turn to the configuration section of your DOS manual. The description in the DOS 3.x manual is very good, and should more than answer any questions. Opus CBCS 1.0 -25- Opus Installation STACKS=n,s The internal stack handling in DOS 3.2 and higher has provided a new "feature" for those who want to lock up their keyboards (and screens, and disk drives . . .) To prevent lockup when repeated interrupts overrun DOS's stack, you may wish to include something like the following in CONFIG.SYS: STACKS=18,256 That doesn't mean "eighteen-thousand, two hundred fifty six." It's actually 18 stack frames of 256 bytes--plenty for Opus. +-------------------------------+ | Suggested settings: | | | | FILES=40 | | BUFFERS=40 | | DEVICE=ANSI.SYS | | STACKS=18,256 | | | +-------------------------------+ AUTOEXEC.BAT Opus also requires a couple of lines in your Autoexec.bat file. While this is also a good place to install one-time options and resident programs, bulletin boards do NOT generally get along well with memory resident software such as dPath or Ready! Anything that installs its own keyboard routines may cause conflicts with the bulletin board routines. You can try whatever programs you want with Opus, but there is no guarantee that they will work. If your Opus is turning weird, uninstall any memory resident programs, and see if the problem stops. FOSSIL Autoexec.bat is the place to install many FOSSIL communications programs; some versions, however, are drivers and must be installed via CONFIG.SYS. Please check the documentation for the FOSSIL you will be using. Opus CBCS 1.0 -26- Opus Installation Set TZ= Internally, Opus works in Greenwich Mean Time. You needn't be exposed to this, because Opus tries to adjust to your time zone by using a DOS environment variable called TZ. This is standard for programs written in Lattice or Microsoft C, and you may have already set this if you are a C programmer. If not, you will need to tell DOS the time difference between your location and Greenwich Mean Time. It's really not difficult; you can set it once and forget about it. Following are examples for the US. The format for the variable is xxxyyy where xxx is the three letter designation for your time zone (i.e., EST for Eastern Standard Time), and yyy is a two digit signed number signifying the difference from Greenwich Mean Time to your time zone. Countries west of Greenwich have a positive number; east, negative. The sign is required in the definition. Here are the examples for the United States: Atlantic For standard time.......... SET TZ=AST+04 For daylight time.......... SET TZ=ADT+03 Eastern For standard time.......... SET TZ=EST+05 For daylight time.......... SET TZ=EDT+04 Central For standard time.......... SET TZ=EST+06 For daylight time.......... SET TZ=EDT+05 Mountain For standard time.......... SET TZ=EST+07 For daylight time.......... SET TZ=EDT+06 Pacific For standard time.......... SET TZ=EST+08 For daylight time.......... SET TZ=EDT+07 Opus defaults to Central Standard Time, which is CST+06. If you are in the central time zone of the U.S., you don't have to set this, although it is still a good idea. Opus CBCS 1.0 -27- Opus Installation Subdirectories (See Appendix B for a complete list of Opus and support files.) * Create these subdirectories: C:\OPUS C:\OPUS\HLP C:\OPUS\MISC C:\OPUS\OUTBOUND C:\MSG C:\MSG\GENERAL C:\MSG\NET C:\FILE C:\FILE\GENERAL C:\FILE\NET * Type "CD \OPUS" to set default drive * Copy the installation kit to C:\OPUS. * Copy your EXE package (OEXE_100.ARC) to C:\OPUS and UnArc it. * Do one of the following: New sysops: Run the MK_USER program to create the file USER.BBS. It works like this: MK_USER firstname lastname password No item is optional. Grizzled veterans of Opus 0.00 or Fido<tm> v11w... Copy your existing USER.BBS file to C:\OPUS. The Opus user file is structurally compatible with both of those systems. Please note that your own user record should be the zeroth (0th) item in the user file. The user in that position gets enhanced "last message read pointer" capabilities. Also, please note that the first item is called the zeroth item. In most things, you'll find that Opus is zero-based. Some user file utilities begin with "1" which throws all user record numbers off by a digit. Opus CBCS 1.0 -28- Opus Installation Everybody: * Copy your Help Sub-System (OHLP_100.ARC) to C:\OPUS\HLP, and UnArc it. * Copy your Misc File Package (OMSC_100.ARC) to C:\OPUS\MISC and UnArc it. * Type "COPY OPUS.CTL BBS.CTL" and press <enter> * Using a text editor, edit the file BBS.CTL. You will need to check/change the following lines: +---------------+---------------+-------------------+ | THE WORD TO | APPROXIMATE | | | LOOK FOR... | LINE NUMBER | NOTES | +---------------+---------------+-------------------+ | Baud | 117 | maximum baud rate | | | | your system can | | | | handle. Remove | | | | the "%" from in | | | | front of the baud | | | | rate that applies.| +---------------+---------------+-------------------+ | Modem init | 210 | Modem type. Most | | | | major brands are | | | | listed. Remove | | | | the "%" from in | | | | front of the line | | | | shown for your | | | | modem. | +---------------+---------------+-------------------+ | Sysop | 600 | Your name. | +---------------+---------------+-------------------+ | System | 620 | Your board's name.| +---------------+---------------+-------------------+ Please try to resist the temptation to change anything else. * Type "OPUS_CTL BBS" and press <Enter>. This step turns BBS.CTL into the BBS.PRM file used by Opus. If you are missing any important files, this is where you will probably find out about it. * Get your FOSSIL program running. For PC-DOS users, this means running Opus!Comm or installing the X00 device driver. Those programs have their own documentation. Opus CBCS 1.0 -29- Opus Installation * Put a time zone entry into your environment. From the DOS prompt, you can type something like this: set TZ=CST4 You can put that line into your AUTOEXEC.BAT file to keep you from having to type it all the time. The TZ means TimeZone. "CST" is the 3-character name of your time zone. The number is the number of hours you are from Greenwich Mean Time. This part is pretty important. If you put the wrong number here, your events will not happen at the correct time. After you are set up, you'll want to study the section of the documentation dealing with this in more details. * Check the contents of any file you're using named LOGO.???. This file will be displayed automatically when a connection is made. Be sure it contains no ANSI graphics and absolutely no IBM-graphics characters. In addition, it should be fairly short. Following these guidelines will a help make matrix connections go more smoothly. * Type "RUNOPUS" and press <Enter>. You should see your modem lights flash. Opus will check out your system. Shortly, you should see the message "Ready" on your screen. Welcome to Opus-CBCS! Things that can go wrong * Be sure you have followed all the above steps precisely. If you have fudged a little on things like the subdirectory names or the control file, un-fudge your system and try it "by the numbers." * Make sure you are running compatible equipment and that it is in working order. * Triple check to see that you have all the required files in their proper place and that you correctly made those three changes to the BBS.CTL file. Opus CBCS 1.0 -30- Opus Installation +-------------------------------------------------+ | | | "In case of fire, yell FIRE." | | | | --- the management | | | +-------------------------------------------------+ Opus-CBCS From The Inside: This section is a walking tour of the system. If it important that you go through it step-by-step. In addition to getting familiar with the setup, you'll also be able to check your setup. When you see the "Ready" message on your screen, press the letter "K" (Keyboard mode). The modem's DTR light should go out and you should see your name on the screen in the form of a question: Adam Bomb [Y,n]? _ Press ENTER to answer YES. When Opus asks for your password, type it. Then press ENTER. Opus displays dots instead of letters when you are typing your password (in case somebody is looking over your shoulder). After some high-tech displays and welcome screens, you should find yourself at the main menu. Type "!" (exclamation point) at the main menu... then press ENTER. If "!" isn't a menu option, you aren't setup as a sysop. You can use a user file utility such as REM_SYSOP to adjust your access level. The sysop menu looks like this: SYSOP A)rea maintenance M)atrix setup E)vents P)riv. (menu) O)utside Q)uit Type "A" and press ENTER. You'll find yourself at the Area Maintenance menu. Opus CBCS 1.0 -31- Opus Installation Change from area zero to area one. Type "A1" and press ENTER. WHEW... are you getting tired of "and press ENTER"? I know somebody who's tired of typing it. <wiping brow> Just remember to press ENTER after ever command and I'll stop hounding you about it. Type "T" (for TITLES). Then type "M" for Message area title. Opus will ask you to type a description of your message area. This is the title that users will see. Type "General Messages." Select "T" for titles again. This time type "F" for File area title. Give some sort of clever title to your file area #1. Type "MY FIRST FILE AREA" or something. You have about 50 or so characters. Type "Q" to quit the area maintenance section. From the sysop section menu, select E)VENTS by typing "E." You should see the EVENT MANAGER menu. Type "C0" to tell Opus you want to change event slot zero. You don't have to do anything here... other than gawk. IMPORTANT: It is absolutely required that you have at least one enabled external event. Opus will get thoroughly confused without it! The RUNOPUS batch file is setup to recycle on the pre-set external event. The system comes with these events already setup: YELL ..... 6:00pm - 9:00pm Z ........ No Outbound, all day eXternal.. midnight, 1 minute Type "Q" to quit the Change Event menu. Type "Q" again to quit the Event Manager itself. Type "Q" once more to quit the sysop section. You should now find yourself at the main menu. Press "G" for goodbye. Opus CBCS 1.0 -32- Opus Installation Your basic installation is now complete. The best course at this point is to print out the manual, and spend a couple hours reading it. Opus CBCS 1.0 -33- Opus Installation MMMMMMM MMMMMMMMMM MMMMMM MMMM MMMM MMMMMMMMMM MMMMMMMM MMMMMMMMMM MMMMMMMM MMMM MMMM MMMMMMMMMMM MM M MM M M MM M MM MM MM MMM MM MM MM MM MM MM MM MM MM MM MM MM MM MMM MMMMMMM MMMMM MM MM MM MMMMMMMMMMM MMMMMMM MMMMM MM MM MM MMMMMMMMMM MM MM MM MM MM MM MM MM MM MM MM MM MM MM MM MM MM MM M MM MM M MM MM MM MM MMMMMMMM MMMMMMMMMM MMMM MMMMMMMM MMMM MMMMMMM MMMMMMMMMM MMMM MMMMMM MMMM There are four fundamental ways to customize your system: * The SYSOP menu on-line. To get there, use "!" (exclamation point) from the main Opus menu. * The CONTROL FILE. This is the single best place to find ways of customizing your system. The sample control file (OPUS.CTL) in the installation kit has line after line of comments. Start at the top, and you'll have a good working knowledge of Opus by the end. * External programs provide lots of help. Here are a few: REM_SYSOP by Bernie Lawrence ... a user file manager OEVENT by Doug Boone ........ spiffy event editor * BBS/GBS files offer room for the most creativity. You can use embedded commands and binary color codes to create lavish widgets for callers. How to set up a new message area * Create a subdirectory for the message area * Get to the sysop menu ("!" from the main Opus menu) * Select A)rea maintenance from the sysop menu Opus CBCS 1.0 -34- Opus Setup * Type "A" then the number you want to use for the new area. This can be any number between 0 and 99. NOTE: Areas should be numbered consecutively, except in special circumstances. If you skip a number, all higher-numbered areas will be invisible to callers. They will be accessible, but they won't appear on the menu displays. If this really is a never-used-before area, Opus will say something like "No area #2. Create one [y,N] ?." Type "Y" to say YES. You should see a screen full of options. Go through the options one by one: PRIV REQUIRED set the minimum access level you want to require to get into the area. Most callers will be NORMAL. New areas are created with an access level of SYSOP. MESSAGE PATH select "M." When asked, type the path to your new message area. This would be the subdirectory you just created. For example: "C:\MSG\TECHTALK\." Most likely, Opus will complain that it can't find the file DIR.BBS. This is a normal reaction. Don't worry about it. If there is no DIR.BBS, Opus will tell you. Then it will say "Continue anyway?" Type "Y." KINDS select the KINDS of messages you want to allow in the area. The KINDS line should say "Local, Public+Private Messages." This is just what you want in most cases. TITLE Select "T" then "M" to setup a description of your message area. You have about 50 characters available. This title is used on menus and area listings. Q)uit the setup section. Say G)oodbye from the main menu, and get off line, for crying out loud. Callers out there are waiting to use your new message area! Opus CBCS 1.0 -35- Opus Setup Message area maintenance Message are stored in individual files. Message #1 is in a file called "1.MSG," for example. Large gaps between message numbers can cause big on-line delays. There are several public domain message renumber utilities (e.g., QkRenum and Renum). You should renumber message areas regularly. In addition, several public domain utilities are available to automatically kill messages by age. This keeps you from taking up disk space with old material. One thing you probably shouldn't do too often: reorganize your physical drive. Several utilities are available (e.g., Optimize and DOG) to do such things. They are handy and highly recommended. In technical terms, these programs "de-fragment" your disk. Running the programs too often, however, causes extra wear on your disk drive head actuator(s). Run them once a month or so. How to set up a new file area * Follow the steps for setting up a message area. * Instead of a message path, setup DOWNLOAD and UPLOAD paths. The download path is the subdirectory containing file you want to make available to callers. The upload path is the subdirectory to hold any files that callers might send to you. * Copy any downloadable files into the subdirectory. * You should find a file called FILES.BBS in the subdirectory. Use a text editor to list the downloadable files. Make sure the file name starts in the far left column. You can type a short description of each file, but remember to leave space on the line for a date. Opus automatically inserts the file's date when it displays the FILES.BBS information. Opus CBCS 1.0 -36- Opus Setup Color is added automagically by Opus. You don't have to mess with it. IMPORTANT: FILES.BBS ABSOLUTELY CANNOT END WITH A CONTROL-Z CHARACTER. Some text editors enjoy putting ^Z's at the end of a file, but Opus doesn't like ^Z's at all. If your editor insists this, you need to run FILES.BBS through a filter such as "STRIP_Z.EXE" before putting the system on-line. File area maintenance Opus keeps a list of files for each file area. It's in a text file called FILES.BBS in the area's subdirectory. Unless a file is listed in FILES.BBS, callers with an access level of NORMAL or below can't download the file. When a user uploads a file, Opus will automatically put the file into FILES.BBS. Adding and deleting files and editing FILES.BBS is about all there is to file section maintenance. Opus CBCS 1.0 -37- Opus Setup ### ### ######## ######## ######## ###### ## ## #### #### ## ## # ## # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #### ## ## ######## ## ####### ## ## ## ## ######## ## ###### ## #### ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ###### ## ## +---------------------------------------------+ | | | "Arrogance is the mother of invention." | | | | - Guido Palermo - | | Opus Bylaws and Covert Action Committee | | | | | | | | Actually, Guido just claims this | | quote. When I checked, the quote's | | serial number had been filed off... | | so it's impossible to tell for sure. | | | +---------------------------------------------+ This is a general explanation of the methods involved with sending messages from your system to other systems. IMPORTANT Old hand or no, if you skip this section, you are going to have a hard go of it later! The reason is that Opus 1.0, in its treatment of mail, is almost, but not quite entirely unlike Fido<tm> and Opus 0.0 (apologies to Douglas Adams. Netmail phone connections work like other systems. It's the operation from sysop's point of view that is so different. It's important to set up your head for all of this before you set up your computer. There's no rule that says you have to get Opus Opus CBCS 1.0 -38- Opus Matrix Outbound running today, so please kick back and enjoy reading how Opus does mail. It'll save you time in the long run. IF YOU'RE AN OLD HAND, be forewarned that some of the ideas will seem very different. You old hands may now jump ahead to page 49. Please leave quietly; the rest of us will be along soon. Netmail for the complete novice: Introduction This section is dedicated to the sysop who has no previous experience with netmail. If you follow the step-by-step instructions, you will quickly set up simple node-to-node netmail and one echomail conference. This does not cover netmail comprehensively, but it will get you up and running without a lot of frustration Advanced netmail topics will be covered in other sections of the documentation. The novice's introduction to netmail is overwhelming, with all the jargon and programs that abound: +-----------------------------------------------------+ | ECHOMAIL PACKETS setmarks | | | | killdups NETWORK TOSSMAIL NODES | | e | | Testlist tidymail Xlatlist | | i | | Route LISTGEN routegen | | k | | NODELIST SEEN-BY Prune | | m | | Setmark ---1.36 NMH IFNA | | | | net REGION BUNDLES | | y | | Inbound Host HUB SCANMAIL newscan | +-----------------------------------------------------+ NO WONDER IT'S CONFUSING! Unfortunately, no single source of documentation or information covers it all. At the time of this writing, the Fidonet<tm> was only three years old, and Echomail, just over a year. With Opus, things are much simpler, yet very complicated situations can be handled. Opus CBCS 1.0 -39- Opus Matrix List of programs for netmail: If you peruse an active Opus or Fido<tm> bulletin board, you will probably see many programs for doing all kinds of wonderful things. But we are trying to save time and get you going. So here is a list of what you will need: oMMM from your Opus kit. Used to package up messages to send to other systems NODE LIST This is your "phone directory" of other systems. Its will be in a file named something like NODELIST.107 (the 107 means it was published on the 107th day of the year). It is published weekly by the International Fidonet Association in St. Louis, Mo., U.S.A. XLATLIST by SEA Used to translate your NODELIST to a form usable by OPUSNODE. It is sometimes packaged in an archive, XLATRGEN.ARC, but all you will need for now will be XLATLIST.EXE and XLATLIST.CTL. OPUSNODE from your Opus kit. Used to compile the output of XLATLIST. ARCA.COM by V. Buerg Used to create compressed mail bundles. DO NOT SUBSTITUTE ANY ARCHIVE PROGRAM THAT CREATES ARCHIVES DIFFERENTLY FROM ARCA. In particular, the "squashing" algorithm used in PKARC by Phil Katz is not allowed in the Matrix. ARCE.COM by V. Buerg Used to unpack mail bundles from other systems. An overview of node-to-node mail Opus CBCS 1.0 -40- Opus Matrix Most novices are quickly confused by the complexities of netmail, but would appreciate a simple overview. The following flowcharts show the paths of incoming and outgoing mail bundles and which programs operate on them. Note that once your node list is compiled, only four programs are required to handle all forms of node-to-node mail: OPUS, ARCA, ARCE, and OMMM. Opus CBCS 1.0 -41- Opus Matrix The incoming message bundle <Incoming message bundle> | | | v Opus (Matrix session) | | v ARCE (only called if mail bundle | must be de-compressed) | v Opus (message unpacker) <Bundle is now broken apart into individual messages> | | v [Matrix Message Area] Note: Only one of your message areas in Opus can be declared as a Matrix message area Opus CBCS 1.0 -42- Opus Matrix The outgoing mail bundle [Matrix message area] | | | v oMMM (creates mail bundles | from individual messages) | | v ARCA (called by oMMM only if mail | bundles are to be compressed) | v <mail bundles ready to send are put into "outbound hold area"> | | v Opus | | v <outgoing mail bundles> Quick start to netmail This section will list each step required to get node-to-node netmail working. It is a "cookbook." The steps are explained in detail after this section. This section assumes your Opus system directory is C:\OPUS. If it is not, you will need to substitute your own directory name in the instructions. * Place these programs and files in you Opus system directory: OMMM ARCA ARCE XLATLIST XLATLIST.CTL OPUSNODE LATEST NODELIST.??? from IFNA (You may find a NODELIST.A##, which is an ARC'd node list which needs to be unpacked before using with XLATLIST. Opus CBCS 1.0 -43- Opus Matrix * Edit the XLATLIST control file (XLATLIST.CTL) to represent your phone costs and local area code (see instructions included with the XLATLIST program) * Translate the nodelist by running XLATLIST. * Compile the nodelist by running OPUSNODE (instructions included with OPUSNODE) * Create the following directories: C:\MSG\NET\ C:\FILE\NET\ C:\OPUS\OUTBOUND\ * Create a network message area using the sysop menu in Opus. It should reference the directory C:\MSG\NET\ and the message type should be "Matrix." * Test the integrity your setup by using the P)oll option from the M)atrix menu at the local console to call a known node in your local area. This part is really satisfying if everything works correctly. * Create a batch file to invoke OMMM for moving messages to the outbound area. Let's call it MASH.BAT. It should have three lines: C: CD \OPUS OMMM -HC:\OPUS\OUTBOUND -MC:\MSG\NET -IC:\OPUS * Login from the local console. Enter a message in your Matrix mail area to a sysop of a local node, preferably one running Opus, that can accept mail at any time. You can then mark it as "Crash." After logging off, run the MASH.BAT file. Look for a screen report that it is processing the message. If you can call the M)atrix menu and select I)nformation, it should show your message in the outbound area, waiting to be sent. After logging off, Opus will wait a couple of minutes, then attempt to send the message. If you are anxious, you can select the C)all option from the local console. This will Opus peek in the outbound area and send mail immediately. You can try it again with a file attached. Just attach a file when entering a message in the Matrix message area. Opus CBCS 1.0 -44- Opus Matrix * Test your ability to receive and unpack mail by having a local sysop send mail and files to you. If everything is working correctly, you will see it come in, get unpacked, and automagically placed in the correct areas. The node list The node list is simply a "telephone directory" of other FidoNet<tm>-compatible systems in the Matrix. It contains information about each system's name, location, sysop, maximum baud rate and special information on operating times and types of mail that can be processed. A new node list is created each week in St. Louis by the International FidoNet Association (IFNA). You can usually obtain such a list from anyone that runs a FidoNet<tm>-compatible system that handles netmail. You could create your own nodelist using an ASCII editor, but that would be very cumbersome. CONFIGURATION FOR NETMAIL - The BBS.CTL file There are several options in your BBS.CTL file which must be set in order to handle net mail. These options appear in two sections of the control file, "Dialing" and "The Matrix." Since this section is devoted to the novice, several non-essential advanced options will be skipped. DIALING PREFIX -- the code sent as a prefix for dialing your modem: Modem dial prefix ATDT,, If your phone only supports pulse dialing it be: Modem dial prefix ATDP,, The is where you could add any special codes required for ALL outbound phone calls. Codes unique to a phone number are defined in XLATLIST.CTL. DIALING SUFFIX -- the code sent after the phone number. Usually just a carriage return, shown as: Modem dial suffix | Opus CBCS 1.0 -45- Opus Matrix MATRIX ADDRESS -- This is essential for sending/receiving netmail. You are normally assigned a number by a coordinator for your region or net. Information on coordinator locations is located in the nodelist published by the IFNA<tm>. Before you are assigned an official number, you should use a -1/-1 as your address. Un-comment this line in BBS.CTL: Matrix Address -1/-1 Other local sysops can temporarily patch your phone number into their *nodelists until you have an "official" number. SUBDIRECTORIES USED BY NETMAIL -- several new directories are required to support netmail. INBOUND MESSAGES DIRECTORY -- un-comment this line in BBS.CTL: Matrix Messages C:\MSG\NET\ Note the trailing "\"! The directory can be anywhere you want it to be. But note that it should be the message area you declared as being Matrix. (See "How to set up a new message area" in the SETUP section of this documentation. INBOUND FILE DIRECTORY -- un-comment this line in BBS.CTL: Matrix Files C:\FILE\NET\ This is the subdirectory Opus will use to store files that are sent to you by other systems. OUTBOUND DIRECTORY -- un-comment this line in BBS.CTL: Matrix Hold_Area C:\Opus\Outbound\ This directory can be anywhere you want it to be, but it the one shown is recommended. Some programs will use this directory as the default for the outbound area. Opus CBCS 1.0 -46- Opus Matrix LOCATION OF THE NODELIST -- un-comment this line in BBS.CTL: Path NetInfo C:\Opus\ Note the trailing "\" ! The directory can be anywhere you want it to be. OPUS DEFAULT BEHAVIOR FOR NETMAIL ACTIVITIES OPUS can do be configured in many different ways to accommodate the many variables in netmail as well as your own preferences. Some of the variables in netmail are: your own system configuration cost of phone calls scheduling mail traffic to conform to local or national schedules viewability of various attributes associated with a netmail message while reading messages in Opus. the ability to define various attributes of a netmail message. Rather than attempt to explain it all here, we are going to make some assumptions to keep it simple. You may wish to change things later. First, we will assume that your system has 256k memory available to run Opus. Second, we are going make some decisions for you about preferred behavior to get you going quickly. Long explanations and justifications are omitted to avoid confusion. Edit your Opus control file to enable the following options: Matrix After Edit Exit 11 Matrix Send LOCAL MATRIX Kludge HIDDEN MATRIX Extract ARCmail MATRIX Toss Echomail Echo Seenby HIDDEN Matrix Ask Crash Sysop Matrix Ask FileAttach Sysop Matrix Ask KillSent Sysop Matrix Scan Echomail Echo Exit 7 Matrix ABOUT c:\opus\mysys.lst Matrix OKFILE c:\opus\okfile.lst Matrix AVAIL e:\opus\myfiles.lst Opus CBCS 1.0 -47- Opus Matrix Your Opus distribution may come with a Z event enabled. Go to the event menu and disable all Z events. This will allow Opus outbound netmail behavior to default to the control file settings. To confirm this is true, go to the Matrix menu (press "M" when Opus is waiting for a call). Select the I)nformation option. At the top of the screen it should say: Matrix Capabilities LOCAL Opus CBCS 1.0 -48- Opus Matrix Matrix overview for the grizzled (who rejoin us here) A new way of thinking about mail Doing outbound mail with Opus is fairly simple. In fact, getting that message across has been one of the toughest jobs. Some of the beta testers say most of their work fell into one of two categories: * deleting lines of batch and routing files * convincing themselves that fewer lines of instruction would do just as well Idea #1 With Opus, "mail events" are less important. In fact, they don't even exist. Instead, we'll be dealing with "behavior windows." With an event, you have to give every detail... making statements that are procedural in nature. With a behavior window, you paint with a wide brush telling the system what to do with classes of remote systems. When systems could handle Matrix traffic only during special times, routing and times were important. Because more and more systems can process mail at any time, the idea of a schedule becomes less important. The item of prime importance in Opus is COST. We are going to try to relieve you of the tedious details of scheduling and concentrate on doing things for the least cost. More on this later. Idea #2 Another new idea deals with the way bundles are created. A "bundle" is what some other systems call a "packet." In network operations, a packet has a special meaning... a meaning that has nothing to do with network mail. An "XModem Block" is a packet in network terminology. To avoid confusion with an established word, Opus docs use "bundle." Opus CBCS 1.0 -49- Opus Matrix Anyway... you are probably used to seeing bundles generated several times. With some programs, bundles are built every time a mail schedule starts. As a result, one message may be put into a bundle several times. With Opus, bundles are built once by an external program called oMMM (the Opus Matrix Message Masher). The original version of oMMM was written by Wynn Wagner, but the program was adopted by Bob Hartman, who has added lots of widgets and handy features. Idea #3 The driving forces of outbound traffic are file names! You'll have a special subdirectory set aside just for bundles and other Matrix files. It's a subdirectory that belongs to Opus and shouldn't have anything else put in there. Opus will maintain this subdirectory for you. It's kind of a "black hole." David Finster says having messages disappear into it takes some getting used to. As soon as you run oMMM, messages that are marked KILL/SENT in your Matrix message area will disappear. They haven't been sent, yet. They're just bundled and ready to go. File names are important to Opus... Bundle names The file names of the bundles tell Opus how to treat the different bundles. Here's a typical bundle name: 12345678.OUT That says the bundle is for 1234/5678. The numbers are in hexadecimal (base 16). The ".OUT" means it is a regular bundle. Other bundle extensions include: .HUT .... hold the bundle for pickup .CUT .... the other system can receive continuous mail One nice thing is that you can manually change the file's extension if you need to. That would change the behavior of the bundle the next time Opus sees it. Opus CBCS 1.0 -50- Opus Matrix The oMMM program knows about these extensions and creates them based on information you put into the oMMM control file. You'll have statements like this: HOLD 124/102 That would create a .HUT bundle file. Flow file names Files are also sent through the Matrix. oMMM builds and maintains a file that tells Opus what files to send (or hold) for whom. A typical "file attach" file might be named: 12345678.FLO Other flow file extensions are: .HLO .... hold these files for pickup .CLO .... the other system can receive continuous mail A flow file is just a text file. It contains a list of files that are to be sent to another system: e:\net\outbound\00096581.mo1 e:\pascal\notes.doc File names in a flow file never include wildcards. Archived messages The oMMM program will put messages into archives for you. Details on this is done may be found in the oMMM section. The point is that oMMM combines the functionality of "generating packets" with that of programs like ArcMail. oMMM creates archives using the same numbering convention as other message archive programs. The file name is the difference between the sender's net/node and the receiver's net/node. The file extension is ."MO#" where `#' is a number between 0 and 9. In this case, MO stands for "messages for outbound" and has nothing to do with Monday. oMMM will NOT produce a "TU" or "WE" (etc) file. How it all works Opus CBCS 1.0 -51- Opus Matrix So far, we've covered bundles and flow files. We've also hit on some of the high points of oMMM. Here's the flow of a message... Let's say I've written a message to Mike Kelleher. The message is in my Matrix message area and is flagged KILL/SENT. oMMM is executed, and converts the message into a bundle. In my control file for oMMM, I have this: CRASH 161/521 161/ALL The word "crash" is VERY misleading. We just haven't come up with a better word, yet. CRASH in this case means that Mike (161/521) runs a system that can receive continuous mail. This control file line tells oMMM to build a message archive to 161/521. In the archive will be any messages to Mike (521) as well as messages to anybody else in net 161. When the dust settles, you'll have a file called "00A10209.CLO" and another one with an ."MO1" extension. The message is now in queue. +-------------------------------+ | | | "Roads? Where we're going we | | don't need roads." | | | |- from Back To The Future | | | +-------------------------------+ Enter Opus, stage right Opus can tell by looking at the outbound subdirectory (called the HOLD AREA) that there's a bundle for Mike. Opus infers from the .CLO extension that Mike's system can receive continuous mail. It's in the middle of the afternoon. Phone rates between Dallas and San Francisco are the highest they'll be all day. It's a bad time to call. We aren't controlling calling times because of our software. The software doesn't care. Both ends can handle Matrix traffic Opus CBCS 1.0 -52- Opus Matrix anytime. We're controlling calling times based on the phone rates. I have a Z-EVENT set in Opus that tells the system to make daytime calls only to local systems that can receive continuous mail. Z-Event: The behavior window A Z-EVENT is setup using the Opus event manager. It starts out looking like any other event... except that it has a Z for a tag. In addition to the start time and event length, there are several yes/no questions that go along with a Z-EVENT: Local only? ....... YES: only make calls to systems whose cost field is 0. NO: it's okay to make calls that cost money #CM only? ..........YES: only call systems who have .CUT and/or .CLO files NO: not restricted to continuous mail systems Mail only? .........YES: don't let human callers on- line, concentrate on mail. NO: humans and the Matrix coexist. File requests ok? ..YES: let other systems make file requests NO: don't allow file requests During the day, I have a Z-EVENT that has LOCAL, #CM, and FILE REQUESTS set to YES. I don't want to make long-distance calls, and I don't want to call systems that can't handle mail on a continuous basis. Poor Mike, just hanging out So, there sits the .CLO file for Mike (see EXAMPLE above). Although it says Mike's board can accept mail on a continuous basis, the COST field in the node list for 161/521 isn't zero. It's a long distance call. Opus will not call 161/521. At midnight, the phone rates are lower. I have another Z-EVENT that allows #CM only. In other words, at midnight I drop the requirement that all calls be local. Opus CBCS 1.0 -53- Opus Matrix At that point, Opus will start trying to send the stuff. (Knowing Mike's board, it will take all night to get it through!) Z-Event overview Here's how my Z-Events go... Daytime ..... #CM, LOCAL Overnight ... #CM NMH ......... MAIL_ONLY For NMH (National Mail Hour), I drop the #CM requirement. That let's Opus send to systems that can't handle continuous mail. The point to all of this is that messages stay bundled all the time. What changes is the behavior of Opus. That's about it At this point, the standard reaction is "I have some special cases that this won't handle. I have several pages of routing and batch files to do all this special stuff." This is my experience: sysop thought patterns are what complicate matters. Possibly there are some special cases that Opus outbound can't handle. I haven't seen any. In the rest of this file, you'll find excerpts of NEW.DOCs form various beta releases. There are details on the HOLD AREA (sub- directory), file requests, and dialing scripts. How to set up Opus to receive Matrix traffic * Set up a message area and a file area as described above. The KINDS OF MESSAGES should be "MATRIX." Opus CBCS 1.0 -54- Opus Matrix * In your control file, make sure you have these items set: Matrix Messages [path] (path to your message area) Matrix Files [path] (path to your file area) Path Netinfo [path] (probably "C:\OPUS\") If you have a network address ("net/node number"), include the ADDRESS statement in the control file. ADVANCED USERS: You might want to look at these other items in the control file. They can be used to "fine tune" your handling of inbound Matrix traffic: Matrix after crashmail exit [errorlevel] Matrix extract arcmail Matrix after arcmail exit [errorlevel] Matrix toss echomail Matrix log echomail Matrix Scan Echomail Echo Exit 7 Matrix ABOUT c:\opus\mysys.lst Matrix OKFILE c:\opus\okfile.lst Matrix AVAIL e:\opus\myfiles.lst How to set up Opus to send Matrix traffic Even if you think you know all about Matrix traffic, please set things up this way. After you've gone through all the steps, you can go back and adjust things to suit your needs. The fact is that this simple setup will handle most cases. If you're an old hand at Matrix traffic, you'll notice a stark absence of such things as "routing" and "mail events." All you need to know now is that the result of these steps will be a very powerful Matrix system that is able to handle situations that used to take several pages of routing files and mail schedules. * Go through Receive Setup steps (above) * You will need at least three external programs and one additional data file: NODELIST: the network's "phone book." Updated weekly by the International FidoNet Association. Opus CBCS 1.0 -55- Opus Matrix XLATLIST: a program that takes the raw node list data and converts it into something more meaningful to your locale. For example, it will strip the area codes from local phone numbers. XLATLIST can also process a per-message "cost" item. This is the amount you would charge your users for sending a message, should you decide to give them access to the Matrix message area. Opus will use the "cost" information to decide whether a call to a remote system is local or long-distance. LOOKY HERE--------> Getting the cost information correct is a vital part of controlling outbound traffic! The XLATLIST program produces an intermediate data file called NODELIST.BBS. OPUSNODE: a program that takes the generic NODELIST.BBS data file produced by XLATLIST and turns it into NODELIST.SYS and NODELIST.IDX for use by Opus. oMMM the Opus Matrix Message Masher is a program that takes outbound messages and converts them into "bundles" for transmission. * Run the latest node list through XLatList and OpusNode. * Create a HOLD_AREA subdirectory: C:\OPUS\OUTBOUND\ * Check these items in the control file: Modem dial prefix [dial command] Modem dial suffix [dial command] Zone [zonenumber] Address [net/node] Matrix Hold_Area [path] NOTE: If you don't yet have an address, use "-1/-1" on the address line. Don't just make up an address! ADVANCED USERS: You might want to check out this control file item, "Matrix after edit exit." Opus CBCS 1.0 -56- Opus Matrix * Quadruple check to be absolutely sure that you have a "TZ" environment variable set ... and that your event manager is reacting to it well. When your system is waiting for a call, the "Ready" status message should show information about the next event. See that the time of the next event coincides with your expectations. The "TZ" environment variable can be a little tricky. * Get to the Event Manager (part of the on-line Sysop Section). If you are using the event file (SCHED.BBS) that came with Opus, you probably have a 1440 minute Z-event that says NO OUTBOUND. This event must be deleted... or its slot re-used for something else. You can use L)IST EVENTS to find the slot number... then C)HANGE to delete or re-use. * Set up the following events: The national mail hour The theory is, if you can't get a message to another system at any other time, you can send it during the national mail hour. One hour is supposed to be set aside for Matrix traffic... with no human callers. As far as we can tell, being able to accept traffic during "NMH" is the sole requirement for being listed in IFNA<tm>'s node list. Kind: Z/Matrix Day: ALL Zone: GMT Time: 09:00 (North American National Mail Hour) Length: 60 Internal: Matrix YES: Mail Only YES: Exits Suppressed NO: [everything else] Opus CBCS 1.0 -57- Opus Matrix Overnight long distance This event tells Opus it's ok to make long distance calls because rates are low... but only if the remote systems can receive mail on a continuous basis. Kind: Z/Matrix Day: ALL Zone: LOCAL Time: 00:00 Length: 360 (midnight - 6:00am) Internal: Matrix YES: Cont.Mail Only YES: File Requests Allowed [optional] NO: [everything else] Daytime local-only During the day, when long distance phone rates are high, you should probably tell Opus not to make any long distance calls. In fact, the only calls should be to local systems that can accept mail continuously. Kind: Z/Matrix Day: ALL Zone: LOCAL Time: 00:00 Length: 1080 (6:00-midnight) Internal: Matrix YES: Cont.Mail Only YES: Local Only YES: File Requests Allowed [optional] NO: [everything else] * Set up an oMMM control file. The oMMM program must be run before Opus can send any messages. It converts message(s) into a transmissible form. How to get into the Matrix We're using the term "Matrix" to mean the amateur e-mail network that's sometimes called FidoNet<tm>. The coordinating group for this is the International FidoNet Association. Opus is not affiliated with IFNA or anybody else. The developers of Opus neither endorses nor oppose the idea of such an association. Although this section describes the operation of FidoNet, you should also know two things: * There is nothing to stop you from creating and maintaining your own private node list. Opus CBCS 1.0 -58- Opus Matrix * Because FidoNet is independent, we can't vouch for of any of this information. It was compiled based on experiences in the Matrix, but should not be taken as an official statement from FidoNet or IFNA. Getting into the Matrix consists of getting a Matrix address. Those numbers are assigned by NET HOSTS. Normally, you can't call your net host or log onto his/her system. That isn't the way this works. Instead, you have to send a message through the network requesting an address. When it's assigned, you will get your Matrix address in a return message from the net host. So, by the time you have an address, you will have proved that you have a functioning system! You will have sent and received traffic. Matrix structure The Matrix is a loose collection of independent systems. To break things down into manageable pieces, the Matrix is divided four ways. You'll be dealing with the middle two items for the most part... ZONE ... normally a continent AREA ... a local "net" or region NODE ... an individual system (you are a node!) POINT ... a sub-node (a caller can be a point) Unless you are doing international e-mail, you don't have to worry about zones. Major cities have been designated as NETs in the Matrix. The person who coordinates things in a net is called a NET HOST. Rural areas fall into a REGION. The person who does net host kinds of things in a region is called the REGIONAL COORDINATOR. A NODE is part of a net or a region. The person who runs a node is you. Your system is a node. Opus CBCS 1.0 -59- Opus Matrix Matrix addresses A Matrix address looks like this: 1:124/102.3 That would be zone 1, net 124, node 102, point 3. Most of the time, you'll see the shorthand version of that: 124/102. A host's address is looks like this: NET/0 The host for net #103, for example, would be 103/0. The zero for the second digit is the signal that the address refers to a host. The address of a regional coordinator looks just like a net host's address. Your area Here's how to find your area: * Using a text editor or viewer, look at the NODELIST.BBS file. Search for your city. * Find the line that begins with the word HOST. Here's an example... HOST 102 30 2400 SoCalNet 1-213-874-9484 Los_Angeles_CA This line tells you that folks living in Los Angeles are in net #102. If you live in a small town, you may not be in a net. Rural areas are covered by regions. If your town isn't in the node list, do a text search for your state. Someone in Ohio, for example might find this: REGION 11 30 1200 Central 1-502-762-3140 IL_IN_KY_MI_OH_WI The region coordinator (or "regional host") would have a network address of 11/0 in this case. Opus CBCS 1.0 -60- Opus Matrix Asking for a number * Use Opus to generate a Matrix-area message to your net host or regional coordinator. * Transmit the message. * Wait patiently for a reply. If you don't hear anything for a few days, you might call the hosts system and leave a local message. Getting along Please remember that hosts and coordinators don't get paid. It is a hobby for them. Getting hooked up to the Matrix can be a frustrating experience sometimes. The host knows that... he/she had to go through it, too! It's O.K. to ask for help. After you are hooked up, it's a common practice for net hosts to ask for a deposit to cover expenses. This is normal and to be expected. Most of your long distance traffic will end up being "host routed." You'll send non-local traffic through your host, and nobody expects the host to pay for your long distance calls. The going rate seems to be 15-30 cents per message. When things are finally running smoothly, you ought to consider offering to help. YOU ARE NOT A CONSUMER... this is a hobby where everybody pitches in. In Dallas, sysops other than the host take care of such things as distributing of the weekly node list update, writing/distributing our local sysop newsletter, coordinating the local sysop echomail message area, arranging the notorious sysop picnics, and on and on. There's plenty to do, and no net host can do it all. The point is that being in the Matrix is not like subscribing to a commercial service. Opus CBCS 1.0 -61- Opus Matrix Operating (in) the Matrix Matrix hold area [Control file addition] Opus wants its own subdirectory for outbound traffic. Declare that area like this: MATRIX HOLD_AREA C:\Opus\Outbound\ The system will maintain that subdirectory for you. There are no user-serviceable parts inside. That's not really true. We'll be storing the OUT, FLO, and AM? files there. You can change the names of the files, and that will affect the behavior of Opus. I strongly suggest you don't put other files in this holding area. Outbound Matrix traffic [control file addition] You have two primary methods for controlling phone calls made by your Opus system: the control file and the event manager. The control file method is in effect if there is no event to override it. In other words, Opus will give priority to the event (described later). To disable outbound calls, un-comment this line in your control file: Matrix Send NOTHING To disable long distance outbound calls, un-comment this line in your control file: Matrix Send LOCAL With those two restrictions, Opus now attempts to send any outbound material it finds in the subdirectory declared as your Hold_Area. If you want to keep humans off-line during a critical mail period, include this: Matrix Allow MAIL ONLY Opus CBCS 1.0 -62- Opus Matrix IMPORTANT: See the section called "The Matrix UNschedule." You can over-ride these control file settings with a new kind of event. The "UNschedule" section describes this event. The Matrix UNschedule A new event has been declared. It's event tag "Z" which had been designated "Opus Internal Event." This is a way to override control file settings. +----------------------------------------------+ | | | "But what HAPPENS during this event?" | | | | "Nothing. It's not a real event. A better | | phrase would be BEHAVIOR WINDOW." | | | +----------------------------------------------+ When a "Z" event is in progress, it's settings remain in effect until the next "Z" event. In other words, the settings do NOT RETURN TO THEIR ORIGINAL VALUE at the "end" of this event. Let's say you declare a "Z" event for every day of the week from 9am to noon. The behavior you describe in the "Z" event will be in effect for those three hours. Here's the part that needs to be stressed... at noon, the behavior will remain in effect unless there is a "Z" event declared then. That should probably be repeated... * You can set up Matrix behavior in the control file. If Opus runs into a "Z" event that is in progress, those control file values are gone for the life of the program. * To end a "Z" event, you have to begin another one. In this case, the duration of the event means, "go to these values whenever you find yourself in this time period." * The end of a "Z" event does NOT mean return to the old values. * Whew. Opus CBCS 1.0 -63- Opus Matrix You can use this event to set the following items: Local only. No "Cost" phone calls are made Regular mail. Outbound goes to all (except HOLDs) Continuous mail. Only packets (etc.) marked for continuous mail are sent Mail only. No human callers are allowed on-line No traffic. Outbound mail is turned off Using the "!" command from the main menu, select the event section. Then just set an otherwise unused event to a type "Z." Additional selections will appear; set them appropriately. Matrix bundlings [control file addition] There is no internal bundler (the thing that maintains message bundles destined for some other system). You can exit Opus with a pre-set ErrorLevel to call the bundler program when the contents of the Matrix area changes. For example, if you call and enter a message into your network area, Opus will exit with an ErrorLevel of 11 *after* you have ended your regular session... Matrix After Edit Exit 11 For information on one possible bundling method, refer to "oMMM.".. a stand-alone no-frills bundling program. Matrix File Requests A file request is when one matrix system asks another matrix system for a file. It is something like logging onto the other system and downloading a file, but it is handled during a matrix session rather than a human-caller session. Opus CBCS 1.0 -64- Opus Matrix There are currently two methods for handling network file requests: "bark" and WaZOO. "Bark" is a telink-transfer method used by some non-WaZOO systems. The WaZOO method uses zmodem and offers more capabilities than the older method. NOTE: Opus can *accept* "bark" style requests but never initiates such a request. Enabling requests If you want to allow file requests, un-commend this line in your control file: Matrix allow requests IMPORTANT: See the section called "The Matrix UNschedule." You can override these control file settings with a new Z-event. Approval listing In addition, you will need a file containing a list of files approved for file requests. This is a standard, garden-variety text file. It MAY include wildcards. Declare the file like this: Matrix okfile c:\opus\okfile.lst This is a "raw" list. It should contain nothing other than file names. Only one file name should be on a line. The items must begin in the far left column. Example: c:\dl\pascal\*.* c:\net\node*.a?? c:\dl\forth\this.one ^ | Pretend this starts way over there | <--------------------------------------------------+ Opus CBCS 1.0 -65- Opus Matrix System advertisement and file list Two more declarations will generalize your list of available files. If somebody wants to know what you have on line for requesting, the standard Opus method is to request a file called FILES. When Opus receives a request for FILES, it will automatically transmit the file you declare like this: Matrix avail c:\opus\filelist.arc The other is the ABOUT file. It is sent on file requests for "ABOUT," or when a file request cannot be satisfied. NOTE: Do NOT put comments on the `okfile,' `avail' or `about' lines. In addition to a listing of files, it would be a good idea to include a statement that wildcards are not allowed on file requests (see below). This file can also tell the caller something about your system. You include the extension in the control file... so the file can be a TXT, DOC, ARC or any other kind of file. PLEASE do not use "filelist.arc" as the name of the file. For The POLE, we're using "POLELIST.LST." Using this scheme, every system can have a unique file name. This should make file management much easier on the caller. Implementation restriction The requesting system cannot use a wildcard in the file name. By letting you put wildcards in the list of approved files, it makes it a little tedious to allow wildcards in the request. Not impossible. Just tedious. So... to make things easy on the sysop... I made a design decision to make it harder on the calling system. This will probably change sometime down the line, but I have my hands too full to worry about such stinkin' niceties. As it were. Errors: No such file This version of Opus sends the "about" file if no requested files are available. Opus CBCS 1.0 -66- Opus Matrix BEFORE ANYBODY ASKS No, Opus does not have a method for initiating "bark" type file requests. It can, however, initiate a WaZOO file request by using an external program named oGET. Special Matrix menu When Opus is waiting for a call, you can get to a special Matrix section. Press "M" when you see the "Ready" status line. The menu includes these items: I)nformation: This generates a chart showing the status of pending outbound traffic. P)oll: force a call to another system whether there is any pending outbound mail or not. If a connection is made, Opus will dynamically generate and transmit a dummy message bundle if a real one isn't available. As many as 9 or 10 tries will be made. You can stop the poll by pressing <esc>. If no connection is made after several attempts, Opus will recycle to its on-line ("Ready") state. If a connection is made, you can expect all items for that node to be transmitted ... even those marked as "hold." When you cancel a poll, you may have to press <esc> a couple of times. The first will cancel the current call; the second one will cancel the poll. U)npack: process/toss any PKT files found in the current default subdirectory. This does the same thing as the familiar `-u' command line option. S)can Scans the message areas looking for messages that need to be gathered up into the outbound area Opus CBCS 1.0 -67- Opus Matrix C)lear undialables Resets the "unavailable" counter for any boards that Opus has found to be unreachable, so calls may once again be made to them. Q)uit Takes you back to the previous menu Immediate call: When Opus has outbound traffic but is waiting for a call, you can force it to make a call immediately. Simply press "C" when you see the "Ready" status message. If it has any pending mail (not counting "hold" items), Opus will make a call. In other words, this does not cause Opus to make a call it would not have made--it merely speeds up the process. Sometimes Opus will just flicker your modem lights instead of actually making a call. This is normal behavior. Just select C)ALL again. Unsuccessful connections Version 1.0 maintains a counter. It is incremented when there is an unconsummated connection. Whenever there is a carrier but no Matrix session, this counter gets bumped. PLEASE READ THIS: If Opus finds a counter file showing it tried five times unsuccessfully to call a board, it will not make further calls to that board. You can manually delete a counter file to enable further calls to the board in question. If you have some kind of daily house-cleaning routine, you could put this into your batch file: DEL C:\OPUS\OUTBOUND\*.?$? The path should be your Opus hold area. It deletes all files that have "$" as the middle character of the extension. Every time you use this statement, it will re-enable calls to boards that had unsuccessful tries earlier. There is also a HOUSECLEANING Z-EVENT which will remove these Dollar-Sign Files. Opus CBCS 1.0 -68- Opus Matrix Wild Echomail The unarc routine now uses wildcards. In other words, it will try to unarc "*.MO?" in your Matrix hold area. If you get something from a message archiver other than oMMM (*ie "TU?," "WE?."...), it will try to unarc that specific file. This change means that attached messages are no longer needed for archived messages! oMMM does not produce such a message, and neither FidoNet<tm> nor WaZOO protocol requires such a message. All existing systems work fine without it. New Matrix behavior mask Using the event setup menu, you can now tell Opus not to exit after SQUIRTmail and ArcMail. The mask is called "Exits suppressed" on the menu. If you turn this on, then any "EXIT AFTER CRASHMAIL" and "EXIT AFTER ARCMAIL" in your control file are ignored. NOTE: There was a slight re-wording of the event menu. The "Exit code" for external events is now "X)exit code." Matrix session scripts Instead of (or in addition to) a phone number, the "phone" field of a record in the node list can contain the name of a script file. The script file name and optional phone number must be in the following format: "FILENAME.EXT"123-456-7890 The quotes are mandatory; they tell Opus that this is a script name. The name within the quotes must be the simple filename (no directory path) of a script file in the subdirectory you've declared as being the NET_INFO subdirectory. The phone number, if given, must be in the format shown. It's used only by the AREACODE and PHONE script commands. Opus CBCS 1.0 -69- Opus Matrix Script names may be easily inserted into the node list by using the PHONE and/or DIAL substitution commands provided by XlatList: phone 124/210 "HardWire.Scr" or Dial / 011- 1-201- "PCP.SCR"201- ... 1-919- "PCP.SCR"919- Contents of a script file A script file is created with a text editor. Each line must contain a KEYWORD. In many cases, it will contain other material. The keyword must be in the far *lefthand column of each line. The system is not sensitive to the case of keywords... upper- and *lowercase is the same. Some keywords require additional information. You should put a single space after the keyword, then start typing the additional information. In other words, if you put a keyword then TWO spaces... the second space will be considered part of the additional information. Keywords Remember: in actual practice, the following keywords must always begin appear in the far *lefthand column. Xmit: send something to the modem. As in the modem initialization string in the control file, Opus understands the following special characters: ~ slight pause | transmit a <cr> character EXAMPLE: xmit ATZ| xmit AT|~ATH0| Opus CBCS 1.0 -70- Opus Matrix Dial: transmit whatever additional information appears on the same line of the script, then wait for a modem response. If the modem reports any kind of failure (e.g., "BUSY"), the script will be terminated. NOTE: The dial "prefix" and "suffix" from the control file are NOT used here. EXAMPLE: dial 555-1212 Areacode: transmit the area code portion of the phone number given after the script file name, e.g.: "xxxxxxxx.xxx"@@@-xxx-xxxx This is primarily useful for placing PC-Pursuit calls. EXAMPLE: areacode Phone: transmit the local phone number portion of the phone number given after the script file name, e.g.: "xxxxxxxx.xxx"xxx-@@@-@@@@ This is primarily useful for placing PC-Pursuit calls. EXAMPLE: phone Pattern: designate a text string to be searched for by the WAIT command. Up to 4 such text strings, numbered 0-3, may be searched for simultaneously. Each string may be a single "word" (no embedded spaces) up to 20 characters long. Upper/lower-case ARE significant; a pattern will only be matched by an identical incoming string. EXAMPLES: pattern 0 : pattern 1 OPUS pattern 2 (disables pattern) Wait: wait for any of the text strings previously designated by PATTERN to be received from the remote system. The command will continue until either a match is found, or there is no input from the remote system for the specified number of seconds. The silence timeout defaults to 40 seconds if not given. If no match is found the script is terminated. EXAMPLES: wait wait 20 Opus CBCS 1.0 -71- Opus Matrix Session: in most cases, this will be the last keyword in your scripts. It means Opus should begin a network session with the remote system. The session begins with whacking, if necessary. Then it moves through the SYNC procedure into the exchange of bundles and files. EXAMPLE: session Dos: send a command to DOS. You can process something.or even summon a stand-alone netmail session-handler. EXAMPLE: dos DIR dos ARCA test *.pkt Carrier: if there's no carrier when Opus reaches this keyword, the script will terminate EXAMPLE: carrier Init: go through the normal modem initialization routine. EXAMPLE: init Baud: set the computer's async port to the remote system's baud rate EXAMPLE: baud Checklist: * Script file names are in quotes in the node list phone field. * All script files must be in the NET_INFO subdirectory. * Each line must have a keyword in the far *lefthand column. * Most keywords require additional information. This information should be separated from the keyword by a single space character. * Most script files should end with "session." Opus CBCS 1.0 -72- Opus Matrix Sample script This script, for PC PURSUIT, was done by Rick Huebner: +--------------------------------------------+ | init | | baud | | | | xmit ~~AT|~~ATDT3417733|~(32 squiggles)~ | | carrier | | | | xmit ~|~D~| | | pattern 0 = | | wait 10 | | xmit ~D1| | | | | pattern 0 @ | | wait 10 | | xmit ~c dial | | areacode | | xmit /12,username| | | pattern 0 = | | wait 10 | | xmit ~password| | | | | pattern 0 CONNECT | | wait 20 | | xmit ~~~~|~~~~I|~~~~ATZ| | | | | pattern 0 OK | | wait 20 | | xmit ~ATDT | | phone | | xmit | | | | | pattern 0 OPUS | | pattern 1 SEA | | pattern 2 Fido | | wait | | xmit ~~~~~~ | | carrier | | | | session | +--------------------------------------------+ Opus CBCS 1.0 -73- Opus Matrix Matrix-oriented batch files Any batch file for Opus must be able to respond to the following pre-defined ErrorLevels: VALUE | MEANING | ACTION -------+-------------------------------------+--------- 255 | an internal error generated by | recycle | Microsoft "C." (e.g., stack | | overflow | | | 5 | reserved by Opus | recycle | | 4 | reserved by Opus | recycle | | 3 | extremely serious error (No FOSSIL, | halt | no user file, etc) | | | 2 | minor error (i/o error) | recycle | | 1 | ^C (keyboard halt request) | halt | | 0 | ??? | recycle -------+-------------------------------------+--------- Opus CBCS 1.0 -74- Opus Matrix Sample batch file: +----+----------------------------------------------------+ |Line| Batch file command | +----+----------------------------------------------------+ | | | | 1 | :start | | 2 | E: | | 3 | cd E:\opus | | 4 | Opus %1 %2 %3 %4 %5 %6 | | 5 | if ERRORLEVEL 255 goto start | | 6 | if ERRORLEVEL 8 goto start | | 7 | if ERRORLEVEL 7 goto bundles | | 8 | if ERRORLEVEL 6 goto prepecho | | 9 | if ERRORLEVEL 3 goto end | | 10 | if ERRORLEVEL 2 goto start | | 11 | if ERRORLEVEL 1 goto end | | 12 | if ERRORLEVEL 0 goto start | | 13 | :prepecho | | 14 | E:\Opus\Util\ScanMail -maxmsgs 500 -short | | 15 | :bundles | | 16 | E:\Opus\oMMM -hE:\Opus\Outbound -cE:\Opus\oBUN.Ctl | | 17 | goto start | | 18 | :end | | 19 | | +----+----------------------------------------------------+ NOTES: Line 5. The check for #255 isn't really needed here because the following line (ErrorLevel 8) will end up trapping 255. It's put here to stress that 255 is a possible ErrorLevel. Line 6. Checking for ErrorLevel 8 is a safety measure. It will trap any ErrorLevels above 8, too. In other words, the batch file is saying "If you get anything else just recycle." Line 7. Respond to "Matrix After Edit Exit 7." The ErrorLevel 7 means something in my netmail message area has changed. The only thing we need to do is put the new messages into bundles by calling oMMM. This ErrorLevel happens after somebody types a message in the netmail area. Line 8. ErrorLevel 6 is this: "Matrix After Arcmail Exit 6." It means we've gotten echomail that needs to be scanned then put into bundles. Line 13. PREPECHO calls ScanMail. Note that this falls through to the bundler. Opus CBCS 1.0 -75- Opus Matrix Line 19. With DOS, you always have to have a blank line when the last item is a label. Checklist for goin' online * Make an outbound hold area subdirectory * Quadruple check to make sure that both ARCE and ARCA are on your path. This may seem silly, but some folks had trouble with it. For example, they had changed "ARCA.COM" into "AA.COM" because of a patch message archive program. * Without both ARCE and ARCE on your path, you can expect problems... tragic and/or humorous depending on your attitude. Do this: * From the DOS prompt, type ARCE and press Enter. The Arce program should display a help screen. If it doesn't, don't try to run Opus outbound. ARCE must be on- line. From the DOS prompt, type ARCA and press Enter. If ARCA doesn't respond with a help screen, you need to get ARCA on your path. * Put OpED.BBS into the C:\OPUS\MISC subdirectory. * Put OPUS.EXE and the three new PRIV files into your Opus root subdirectory. * Customize OPUS.CTL and compile it using OPUS_CTL. * Build an oMMM control file * Build a new batch file * Put everything on-line and fly to London for a week. Vince Perriello can probably explain this step in greater detail. The chief cause of problems is solutions. -- Eric Sevareid -- Opus CBCS 1.0 -76- Opus Matrix ########### #### #### #### #### #### #### ############# ### ### ### ### ### ### ### ### #### #### #### #### #### #### ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # ## ## # ## ## # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ### ### ## ## ## ## ## ## ############# ## ## ## ## ## ## ########### #### #### #### #### #### #### +--------------------------------------------------------+ | THE MATRIX: | | The world's first CyberPunk BBS Network | +--------------------------------------------------------+ NAVIGATING THE MATRIX using oMMM: The Opus Matrix Message Masher Original oMMM (now a collectors item) was written by Wynn Wagner III, otherwise known as "Arrogant Hacker I" The program was tweaked/rewritten/cleaned-up/added-to under the care of Bob Hartman, otherwise known as "Arrogant Hacker II" +-----------------------------------------------+ | | | "Hackers - Heroes of the Computer Revolution" | | The story of the whiz kids whose irreverence, | | idealism, and sheer genius changed the world. | | | | - From the cover of a Steven Levy book | +--------------+--------------------------------+--------------+ | | | And some people thought that I would dislike | | being called an "arrogant hacker" | | | | - Bob Hartman, "Arrogant Hacker II" | +-----------------------------------------------+ Opus CBCS 1.0 -77- Opus oMMM +---------------------------------------------+ | | | Technology itself has changed. | | | | Not for us the giant steam-snorting wonders | | of the past: the Hoover Dam, the Empire | | State Building, the nuclear power plant. | | | +--------------+------------------------------+--------------+ | | | Eighties tech sticks to the skin, responds | | to touch: the personal computer, the Sony | | Walkman, the portable telephone, the soft | | contact lens." | | | | - Bruce Sterling | | | +---------------------------------------------+ Quick Review of the Matrix The Matrix is an international connection between individual system operators. Other system operators may be getting access to this "network" using various pieces of software including Fido<tm> and Seadog<tm>. One method for Opus sysops to use the Matrix is a program called oMMM: the Opus Matrix Message Masher. oMMM creates the `.OUT' and `.FLO' files used by Opus-Cbcs for outbound Matrix traffic. Actually, it combines the functionality of such programs as Arcmail[(c)SEA] with the "generating packets" rigmarole previously internal to programs putting messages onto the IFNA<tm>-type network. Opus Outbound <no_tm> (or "OO" for sort) is compatible but not identical to existing IFNA<tm>-type network software. Please do not just assume you understand OO routing just because you are familiar with other<tm> systems. This document assumes you are already familiar with the operation of the IFNA<tm>-type network. Opus CBCS 1.0 -78- Opus oMMM Outbound hold area +---------------------------------------------+ | | | I think it might be in the basement - | | I'll check upstairs. | | | | -M.C. Escher | | | +---------------------------------------------+ Remember: Pending outbound traffic is stored in a special subdirectory called a HOLD AREA. To be on the safe side, you should make this subdirectory just for the holding area. In other words, it is possible (or likely) that Opus will get confused if it finds other material in the subdirectory. Opus considers everything in that area to be "fair game" as far as creating, deleting, and appending is concerned. Methods +---------------------------------------------+ | | | Whenever a system becomes completely | | defined, some damn fool discovers something | | that either abolishes the system or expands | | it beyond recognition. | | | | - Finagle's Fifth Rule | | The Book of Rules | | | +---------------------------------------------+ Other<tm> programs which do IFNA<tm>-type network mail have built-in routines which build bundles ( or "generate packets"). These bundles are sometimes built and un-built several times before they are transmitted. Opus does not contain any internal bundling routines. You have to use an external program, such as oMMM. The reason for this is simple: MEMORY. To do bundling correctly takes vast amounts of memory, and Opus just does not want to share that much memory with a bundler. Opus CBCS 1.0 -79- Opus oMMM There is another reason for keeping it external: clever programmers can write their own bundling programs to handle whatever special cases might arise. The final reason is speed because bundles are built once, then kept current. Opus wants to be ready for Matrix traffic at any time. Therefore, there is no facility provided for un-doing a bundle (i.e., separating a bundle into the individual messages). A special un-bundler utility could be written for such a thing if anybody is inflicted with the need. What's in the holding area You can expect to find three kinds of files being stored in your holding area: OUT files Normal bundles of messages waiting to be transmitted. The extension may actually be OUT, DUT, HUT, or CUT. FLO files A list of files waiting to be transmitted. This file contains the names of all the files to be sent as "file attaches" as well as any archived bundle files built by the oMMM program. It is a standard, garden-variety text file with only one file per line (NO WILDCARDS). The "#" is a special flag that can appear as the first character of a line. If a line begins with a pound sign, the file listed on that line will be truncated if it is successfully transmitted. This is primarily for use with archived bundles. They need to be "nulled" after they are sent. Flow files can have these extensions: FLO, DLO, HLO, and CLO. MO# files Most sysops would call these "ARCMAIL" files. They are bundles of messages which have been compressed using a program such as ARCE or ARC (Mail Outbound). Opus CBCS 1.0 -80- Opus oMMM The file extension will be "MO" followed by a number (0-9). The characters stand for MATRIX OUTBOUND and do not refer to any day of the week. oMMM does not produce any "TU#.".."SU#" files. NOTE: Opus supports a 12-bit LZ compression method. Some programs (*eg. PKARC) use a 13-bit method. They will require far to much memory to run and should not be used for archiving mail. Simple oMMM +---------------------------------------------+ | | | The concept is simply staggering - | | pointless - but staggering!" | | | | -The Doctor | | | +---------------------------------------------+ The oMMM program words in two phases. In its simplest form, oMMM will generate an OUT file for every system which has traffic in your Matrix message area. There is simply no concept of "routing" at this point. If a system has a message, there will be an OUT file. This is a "no-route" kind of operation. The OUT files will eventually be transmitted directly to the destination without going through any intermediate system such as a "host" or "hub." Every time you execute it, oMMM goes through this stage. THE INDIRECT APPROACH +---------------------------------------------+ | | | A man's best friend is his dogma. | | | | -Anonymous | | | +---------------------------------------------+ Opus CBCS 1.0 -81- Opus oMMM Routing in a nutshell - After all of the bundles have been generated, you can use a control file to send messages through a "host" or "hub" or some other intermediate system. In Opus, all indirect transmissions use archived message files. We will be creating an archive of routed files. Here is a sample control file command: ArcTo 136/12 136/ALL This command tells oMMM to build an ARC type file for 136/12 and will include the OUT files for any other system in net 136. NOTE: The "OUT" extension is changed to "PKT" when the messages are archived. You can specify several systems in an ArcTo statement: ArcTo 124/0 130/14 130/20 105/ALL This command will build an ARC file for 124/0. The file will contain any existing OUT files for 124/0, 130/14, 130/20 and all systems in net 105. Flavors of routing "Arcto" is just one of several words you can use to affect the behavior of outbound Matrix traffic. To hold archived mail for pickup by the other system, substitute the word "HOLD" for the word "ARCTO." For example... Hold 141/491 161/ALL This hold command puts messages for 141/491 and all systems in net 161 into an archive and marks the whole thing as "hold for pickup by 141/491." IMPORTANT: The "hold" statement stands by itself. In other words, you don't use hold with another command such as "ArcTo." Instead, "hold" REPLACES the "ArcTo" statement. It does everything that "ArcTo" does with the additional feature of marking the resulting bundle as HOLD FOR PICKUP. Opus CBCS 1.0 -82- Opus oMMM HINT: In the following list, the words ARCTO, HOLD, and CRASH are considered the basic statements. In most cases, you can lead a fruitful/meaningful life with nothing more complicated than those three words. All of the other words are for advanced usage or for special circumstances. (K.I.S.S.!) Here is a list of commands that oMMM understands: SCHED Starts a schedule. All oMMM statements between this statement and the next SCHED statement will be executed if the schedule tag matches the one given on the command line. tag is a character that can be in upper or lower case. SYNTAX: Sched tag ARCTO Send as regular mail during pre-set schedules. This command actually ARC's up the packets just like ARCmail would do, so you must be sure that the receiving system either has ARCmail that runs at regular intervals, or is running Opus 1.00 or higher. SYNTAX: Arcto destination [routelist] EXAMPLES: Arcto 124/0 124/ALL Arcto 135/1 POLL This creates a dummy .OUT file if there are no files existing for the given node that are not on hold. If there are files in the holding area which are going to the given node, and they are not on hold, then the POLL statement will do nothing. SYNTAX: Poll destinations LEAVE Mark all packets to the listed nodes such that Opus will not attempt to send them. Use the -z command line option of oMMM to make the packets be recognized by Opus for future sending. Use this option with extreme care! SYNTAX: Leave destinations Opus CBCS 1.0 -83- Opus oMMM SEND If a node in the destination list has a packet that has been marked as a "do not send" packet by using LEAVE, then make it so that the packet can once again be sent. SYNTAX: Send destinations EXAMPLE to do local schedule with some extra nodes: ; First mark all nodes as no-send Leave All ; Now send to our net and list Send Ournet 132/101 124/108 DOCRASH If a node in the destination list has a packet that has been marked as a "do not send" packet by using LEAVE, and the packet is a crashmail packet, then that packet is marked for sending. SYNTAX: DoCrash HOLD Prepare the archive, but disallow an outgoing phone call. The archive will be held for the other system to pickup. This has the same comment as the ARCTO statement, i.e., the receiver must have some way to unARC the packets. SYNTAX: Hold destination [routelist] ONEHOLD This call is identical to the above call except that all nodes listed have the packets held individually. This allows statements to be used in a program like XlatList<tm> that will hold for a list of nodes. SYNTAX: OneHold destinations CRASH Send to a system which supports continuous mail. Such systems include other Opus systems and Seadog (v4.00). Again, the receiver must have a way to unARC the packets. In the Opus control file, you have some control over continuous mail. See the part dealing with "Matrix send local only." Note that Opus "crash mail" is compatible but not identical to so-called crash mail in other<tm> systems. SYNTAX: Crash destination [routelist] Opus CBCS 1.0 -84- Opus oMMM ONECRASH This call is identical to the above call except that all nodes listed have the packets crashed individually. This allows statements to be used in a program like XlatList<tm> that will crash to a list of nodes. SYNTAX: OneCrash destinations UNCRASH Any packets to the nodes in the list that are marked as CRASH are marked normal. SYNTAX: UnCrash destinations UNHOLD Any packets to the nodes in the list that are marked as HOLD are marked normal. SYNTAX: UnHold destinations NORMCRASH Any packets to the nodes in the list are sent as CRASH type packets that are compatible with other <tm> software. This basically means that the packet is not ARC'd. SYNTAX: NormCrash destinations NORMHOLD. Any packets to the nodes in the list are sent as HOLD type packets that are compatible with other <tm> software. This basically means that the packet is not ARC'd. SYNTAX: NormHold destinations The control file +---------------------------------------------+ | | | There are two kinds of people in the world: | | Those with loaded guns, and those who dig. | | You dig. | | | | - Clint Eastwood | | 'The Good, The Bad, and The Ugly' | | | +---------------------------------------------+ Opus CBCS 1.0 -85- Opus oMMM Contents The oMMM control file is a text file. You can use a semi-colon (";") as a comment character. oMMM will ignore everything beyond a semi-colon on a line. Put the word ARCTO in the far left column. That's followed by the destination board plus 0 or more other systems. Examples: arcto 161/2 ; just archive 162/2's stuff arcto 100/0 100/ALL ; "host route" net 100 Do what I say, when I say it You should consider the control file as a PROCEDURAL file. In other words, oMMM will act on every statement as it comes to it. The control file is a list which says "Do this, then do that, then do whatever." Here's an example of how you can use this kind of operation: arcto 130/12 130/20 arcto 130/0 130/ALL There. Material for 130/20 and 130/12 will go to 130/12. Then everything else to net 130 will be "host routed." The first statement takes care of 130/12 and 130/20. By the time oMMM gets to the second line, material for those two systems no longer exist as individual OUT files. Special words In addition to "ALL" as a special "node number," the words "OTHERS," and "OURNET" can be used as special "net numbers." They mean networks other than our own and your own network respectively. If your net has an outbound system ("Host" or "Hub") then you can route out-of-town traffic to that system like this: arcto 124/0 OTHERS The command with "others" in it should probably be one of the last commands in your control file. Remember, this is a procedural file. Take care of your specific routing, then do the "others" command as a kind of "clean up" command. Opus CBCS 1.0 -86- Opus oMMM NOTE: If you are using XlatList<tm> to create your oMMM control file you will find that it will not pass the keyword ALL through to the control file when it is used on an ArcTo line (or any other line with other node numbers). In this instance, you should use the keyword WORLD which has the same meaning as the keyword ALL. Using oMMM +---------------------------------------------+ | | | No matter what you do today, nor where you | | go, nor whom you meet, there are at least a | | billion red Chinese who don't give a damn. | | | | - Dan Jenkins | | | +---------------------------------------------+ Operational overview You must have the program ARCA.COM available somewhere on your path. The oMMM program needs seven pieces of information from you. Switches: the optional switches that can be on the oMMM command line. The available switches are: -d to disable the conversion of Opus dates back to older Fido<tm> dates. This should not be used unless all connections are made with other Opus nodes. -z to ZAP the entire holding area so that all packets that the LEAVE statement had to modify are returned to normal. -n to disallow forwarding of messages for other boards. Note that you cannot use this switch if you are a host or hub! Opus CBCS 1.0 -87- Opus oMMM Schedule tag: the character corresponding to the schedule which oMMM should use in the control file. -s followed by the character for the TAG.specifies the schedule tag. If you don't specify a schedule tag, oMMM will assume no schedule and process any statements in the control file that are before the first SCHED statement. Info path: the subdirectory that contains the file MAIL.SYS. [NOTE: that file may end up not being needed by the version of oMMM you receive. Please check your distribution package for a READ.ME file - Ed.] -i followed by the name of the subdirectory specifies the info path. If you don't specify an info path, oMMM will use the current default subdirectory. Hold path: the subdirectory used as the Opus outbound hold area ("OO-HA" for short). -h followed by the name of the subdirectory specifies the hold path. If you don't specify a hold path, oMMM will complain at you loudly and will refuse to continue. (Dos ERRORLEVEL=1) Message path: the subdirectory where your Matrix messages are kept. You only need to use this item if you are doing something "non-standard." If you are taking messages from your normal Matrix message area, do not declare any message path. -m followed by the name of the subdirectory specifies the message path. If you don't specify a message path, oMMM will use the path declared in the info file, MAIL.SYS. Opus CBCS 1.0 -88- Opus oMMM Pre-message scan control file: the name of the file containing routing commands to be executed BEFORE message scanning takes place! -p followed by the name of the control file specifies the pre-message scan control file name. If you don't specify a pre message scan control file, no changes will be made to the holding area before messages get scanned. This command is useful for systems that do a lot of 'state changes' during the day. For example, a system may want to Hold mail in an archive for a node at some times, and send it at other times. In this scenario it is very possible that oMMM could create a file attach message, then have that archive placed into the actual archive when oMMM was run again. This is undesirable behavior which can be overcome using a pre-control file. For example, you have just executed a Hold statement for a node which places a file attach message in a .HUT file. Now you decide to send to that node by using the UnHold verb, that places the file attach message in a .OUT file. Finally, the archive was not sent out, so you once again want to hold for the node, normally you would use Hold to do this, but that will packet up the file attach message that is still in the .OUT file. The solution is to use a pre-scan control file to NormHold the node, then in the normal routing file use Hold to archive the new messages (the .HUT will still contain the file attach message and it will not be archived), and after the Hold is executed, an UnHold can be executed if necessary. This sounds a lot more complex than it is. Simply use a pre-scan control file to get your holding area into the same state all the time before the real routing gets done. This will save hours of time trying to determine what oMMM will do under certain conditions. Eventually this may also be used to force oMMM to un-oMMM packets. Opus CBCS 1.0 -89- Opus oMMM Control file: the name of the file containing routing commands. -c followed by the name of the routing control file specifies the control file name. If you don't specify a routing control file, no routing will be done. Example: oMMM -hc:\opus\outbound oMMM -hc:\ob -cc:\routes.ctl One final note about using oMMM. It may sometimes seem like a slow-running program. I can promise you that it is not. Internally, it is screaming out instructions to your computer as fast as possible. Remember: oMMM combines the functionality of an "arcmail" program with the "generating packet" of other<tm> Matrix systems. With oMMM, you only have to generate those bundles once... when the archives are built. Reference stuff: File names +---------------------------------------------+ | | | "You bring the light, | | 'n' I'll bring the tunnel." | | | | - H. Neghila | | | +---------------------------------------------+ What about Opus? Opus will try to send material (not marked ."HLO" or ."HUT"). In other words, it assumes that you and your bundle program know what you want. There is no concept of a "schedule" in Opus 1.0. It will try to dial numbers when it feels like it. Also, there is no concept of a system that is unable to do continuous mail. Fido<tm> systems, for example, are completely unable to receive mail except during a schedule. Older Seadog<tm> systems are not able to hold bundles and files for pickup except during a scheduled network event. Opus CBCS 1.0 -90- Opus oMMM There is definitely a need for a program that can use the "raw" nodelist information ("NODELIST.###" file) to produce a routing control file to ensure material headed for older systems is marked HOLD. Otherwise, Opus will try to call those systems. Here's the Real Bummer: the oMMM program knows diddley-squat about such nodelist flags as "#CM:." oMMM will not put anything on hold. In the Opus control file, you can declare such things as your Matrix hold area. There are flags that say SEND NOTHING (make no outgoing calls) and LOCAL ONLY (make calls only to those systems whose "cost" field is zero). The main point is that Opus considers the hold area current. Opus CBCS 1.0 -91- Opus oMMM ECHOMAIL Echomail is a way for several independent systems to share a message area. The idea for echomail came from Jeff Rush. You will find several national conferences on dozens of technical and non-technical subjects... from Opus to Pascal to science fiction and genealogy. To be involved with an echomail conference, you first have to get a Matrix address. Although echomail is not affiliated with FidoNet<tm> or with IFNA, it would be impossible to handle echomail without their Matrix structure. If you don't have an address, you need to take care of that first. Getting started with Echomail Find an echomail conference you want to carry on your system. This is all fairly informal. Here are some suggestions: * Log onto another local system that carries lots of echomail. Leave a note to the sysop saying "Hey, can I tie into SUCH-N-SUCH on your board?" or "Where can I tie into this area?" * Check your net's newsletter. Many local nets publish an up-to-date chart of echomail conferences. * Don't assume you'll get a helpful hand from your net host or regional coordinator. Remember that echomail has nothing to do with FidoNet<tm>, and some hosts/coordinators don't want anything to do with it. Build an ECHO.CTL file if you are using the internal echomail processor, or refer to the documentation for your external echomail utility program(s). Set up an Opus message area. On the KINDS OF MESSAGES item on the Area Maintenance menu, make sure you tell the system that the area is for ECHOMAIL and that it is to be "NO PRIVATE MESSAGES." (It's normally considered bad manners to transmit private messages in an echomail conference.) In your RUNOPUS batch file, set things up to run oMMM from time to time, to bundle messages for transmission. Opus CBCS 1.0 -92- Opus Echomail The Opus control file has some echomail-specific options. They should all be in one general place in the sample control file. Do a text search for "echomail" to find them. Some of the options are designed to make echomail processing as automatic as possible. Scan control file The internal echomail processing routines look for a file called "ECHO.CTL" on the default drive and subdirectory. The file does NOT begin with a system and sysop name line. Control file lines need to start in the far lefthand column. Items are separated by a single space character. Each line should be terminated by a <cr/lf>. IMPORTANT: Please put a <cr/lf> after the last line! Each line (including the first line) should have this form: number path areaname scanlist NUMBER: the area number PATH: the path to the area being scanned AREANAME: the name of the echomail area SCANLIST: a sequence of 0 to 10 Matrix addresses Examples: 17 c:\msg\sysop SYSOP 124/102 124/111 124/210 5 c:\msg\walrus WALRUS 141/491 ^ | | pretend this stuff starts <---------+ over there Method The scan process is triggered by one of three things: * Echomail messages received through the Matrix. If scanning is enabled, the messages are scanned after all bundles are unarc'd and tossed. Only the areas that have new messages are scanned. Opus CBCS 1.0 -93- Opus Echomail * Human caller entering an echomail message. If scanning is enabled, the messages are scanned after the caller's session. Only the areas that have new messages are scanned. * Selecting S)CAN from the on-line Matrix menu. This is the only way to scan all message areas. Bundles are created as .OUT files in the subdirectory designated as HOLD_AREA. If you need other processing to take place after the scan, you can use the echo EXIT feature. The exit is supposed to happen after messages are scanned. The most likely use for the EXIT will be to call oMMM to get the .OUT files into archives. The Meadow The Meadow is an echomail conference just for Opus sysops. Its distribution is more widespread than just about any other echomail conference. You will be in touch with hundreds of Opus sysops all over the world... from Australia to Holland and Hawaii to Maine. It is one of the best places to discuss problems or pick up hints. If there is ever something like an emergency "recall" of Opus software, word will be put into The Meadow first. (This is a plug for The Meadow. Can you tell?) To get hooked up to The Meadow, you have to agree to the following things: * Restrict access to Opus sysops. This means you need to set the minimum access level to SYSOP for the message area so regular callers can't get into the area. It also means you should send the area only to other Opus sysops. Sysops running other software have their own echomail areas. * Use the area in a lawful and friendly manner. * Keep the discussion on topics of interest to other Opus sysops. There really isn't anybody "in charge" of The Meadow. It's a grassroots conference run primarily by the cooperation and goodwill of Opus sysops around the world. In fact, this is a good time to offer a pat on the back to those sysops who've been involved in The Meadow. It's quite an experience. Opus CBCS 1.0 -94- Opus Echomail Most likely, there's already a local tie-in for The Meadow. If you can't find it anyplace, send an e-mail message to one of the OPUSinfo systems. Other areas To give you an idea of what's around, here are some of the echomail areas that reach Dallas... AMIGA ... Amiga users BIBLE ... Christian conference C_ECHO ... "C" language programmers CHATTER ... general discussions COMM ... modems and communications software ECHOMAC ... Macintosh users ECLOTUS ... Lotus users ECPROG ... for programmers EGA ... fans of fancy video FOR-SALE ... a nationwide flea market FOSSIL ... FOSSIL implementers GAMING ... gambling (I think) GAYNET ... gays GENEALOGY ... family ties IFNA ... International FidoNet Association members JOBSHOP ... nationwide help wanted LIFESTYLE ... aging hippies, probably MEADOW ... Opus sysops NET124 ... for local Dallas sysops PASCAL ... Pascal programmers RECOVERY ... members of Alcoholics Anonymous SF ... science fiction SIRIUS ... sysops who use the Sirius program SYSOP ... system operators TECH ... general computer talk TELIX ... users of the Telix communications program That's a partial list. It's quite a collection. The list of conferences in your area will be different. If you hear of some conference that isn't in your area, you can put yourself in charge of calling to bring it to your area. That's the way echomail conferences spread out! If there simply isn't a conference that suits you, find another sysop who shares your interest and start your own echomail conference. That's precisely how conferences begin. Opus CBCS 1.0 -95- Opus Echomail Routing and coordination Most echomail conferences have a coordinator. That's someone who's supposed to help with hookups and to keep the discussion on track. Most good coordinators are quiet. That's because most echomail conferences rely on the goodwill and cooperation of participating sysops. Some echomail conferences are on what's called "the backbone." That's a collection of mail-only systems that do very little other than send echomail. The primary backbone systems are run by George Lehtola, Bob Hartman, and Gee Wong. They swallow a great deal of the expense in running echomail, and we all owe them our gratitude. Other backbone-class hubs include systems run by Tracy Graves, the Walker brothers, and the Great Dallas Round-Robin. The situation in Dallas is fascinating. There are four systems involved: David Finster, Chuck Lawson, Jon Sabol, and Wynn Wagner. When a batch of echomail hits any of those systems, it is immediately processed and sent to the other systems within a matter of minutes. From there, it's on to other parts of the world. Wynn's system, for example, is the main link to the rest of the backbone. Jon's system takes care of Australia and New Guinea. David handles some local and some national traffic. Chuck deals with local and some regional traffic. The reason Dallas is mentioned is that it's a good example of how efficient routing is possible through an informal coalition of sysops. Not only can Dallas process an unbelievable amount of echomail traffic is a short period of time, the expense of long distance echomail is spread out. Like almost everything else that touches Opus, echomail is a grassroots sort of deal. It isn't a commercial service that has subscriptions, and you are not a consumer. If you get involved, you can be expected to share in the expense and in the responsibility. But that's what makes it a hobby! IMPORTANT: Echomail is never "host-routed." It is always sent directly from one system to another. Please don't attempt to send an echomail conference through your net host or regional coordinator. Opus CBCS 1.0 -96- Opus Echomail How it started Once upon a time, way back in 1985, Chuck Lawson and Harv Neghila noticed they were spending lots of time in chat with each other... running up their long distance bills. "There's got to be a better way," they concluded. "We ought to do something like netmail chat." That subject was brought up at the next notorious Dallas sysops' pizza party. All the sysops had opinions and suggestions, as is expected. Somebody noticed that Jeff Rush had quietly taken out paper and pencil. He seemed to be taking notes. The idea was forgotten--that is, by everyone except Jeff. A month or so after the discussion, he popped up and said, "Here 'tis!" It was a couple of programs which make up the heart of the echomail system... and which had no similarity to any of the designs laid out so carefully on our pepperoni conference table. He wrote a two programs: SCANMAIL, to move outbound messages from an echomail area into the netmail message area, and TOSSMAIL to move inbound messages from the netmail message area into the echomail area. We decided to try it out by starting two echomail message areas. One for sysops, cleverly called SYSOP... one for users called TECH. Messages bounced around (most of the time) between systems run by Chuck Lawson, Jon Sabol, and Jeff Rush. The next day two other message areas were added: CHATTER and POLITICS. Two other systems were added: Wynn Wagner in Dallas and Harv Neghila in San Francisco. Chuck-to-Harv: the first backbone. They were spending their long distance money again. Now, it wasn't just for their chatting. It was for chatting from Jon and Wynn and Jeff, too... and all they users on all five systems. So it went. In short order, other sysops started getting curious and interested. The SYSOP area spread out quickly. One of the earliest battles was to keep Dallas sysops from talking about the most recent picnic or pizza party. It took quite some time for the locals to realize their little local echomail area wasn't little or local any more. <wiping brow> Opus CBCS 1.0 -97- Opus Echomail Another early problem was net hosts and region coordinators. Nobody realized that the volume of echomail would grow so quickly. At first, echomail went out like any other e-mail... through net hosts. Those hosts quickly made it known that they weren't amused by the sudden increase in their long distance bills. That's seems like a reasonable attitude, and everybody agreed that echomail would never be "host-routed" again. "This is going to bring the network to its knees," was the cry from some quarters. So far, though, it seems to be working. The amazing thing is, echomail is working in spite of its lack of a firm organizational structure. The backbone is an informal coalition, and they certainly wouldn't presume to tell you what you can or can't do with echomail... as long as you stay polite. Maybe it should be stated like this: echomail is working BECAUSE OF its lack of a firm organizational structure. Opus CBCS 1.0 -98- Opus Echomail OPERATING OPUS The Sysop section This section describes the on-line Sysop Maintenance section. To get to the sysop menu, use "!" (exclamation point) on the main menu. The sysop section menu looks like this: SYSOP A)rea maintenance M)atrix setup E)vents P)riv. (menu) O)utside Q)uit Area maintenance The area maintenance screen looks like this: Area #0 P)riv required ........ K)inds of messages B)bs menu path......... M)essage path.......... H)elp path............. D)ownload path......... U)pload path........... T)itles Message area...... Download area..... A)nother area Q)uit Area zero is a special area for sysops. It is primarily used to tell Opus where to put messages left by users as they log off. When a user says "G)oodbye," Opus asks if he/she wants to leave you a message. If the user says YES, the message will appear in the subdirectory you've listed as being the "M)essage path. Opus CBCS 1.0 -99- Operating Opus The items on the area maintenance menu: Priv. required Set the minimum user access level required to get into this area. It affects both the message and file sections. When you select P)riv by pressing "P," you'll see a chart of the possible access levels. Most users will be NORMAL. Kinds of messages The "Kinds Screen" lets you describe the behavior of a message area. There are three fundamental areas, Message Types, Message Editing, and Miscellaneous: Message Types M)ATRIX...Matrix message is a message sent from one system to another using the e-mail network. Only one message area should be designated as the Matrix area. Telling Opus that an area is for Matrix messages enables special checking and handling. L)OCAL....A local message is a regular bulletin board message that originates on your system and never leaves your system. If you are setting up a message area just for your callers, it should be designated as LOCAL. E)CHOMAIL.An echomail message is a message that originated on your system but will be broadcast to one or other systems using Jeff Rush's echomail method... or a message that originated on some other system and was broadcast to your systems. Telling Opus that an area is for Echomail enables some additional message processing (*eg. suppression of EchoMail's SEEN-BY information). It does NOT do anything about broadcasting the message. Message Editing !)NO PRIVATE...If you tell Opus not to allow private messages, the system will force all new messages to be public. Most echomail areas are designated as "NoPrivate." Opus CBCS 1.0 -100- Operating Opus $)NO PUBLIC...Use "NoPublic" only if you want to enforce a private message area. R)EAD-ONLY...A read-only message area means users can't enter any messages. They are allowed to read messages, but not post anything. ADVANCED USERS: The idea of a read-only area sounds curious. Consider that there's nothing to keep you from having two logical areas point to the same physical subdirectory for messages. You can setup a high numbered area *forSYSOP access only. In that area, you can post messages such as reminders or bulletins. Then the low-numbered area, accessible to regular callers, can be marked Read-Only. They can read your reminders/bulletins but can't add to them. Miscellaneous A)NON OK..As a novelty, you can mark a message area as allowing anonymous messages. If this is enabled, Opus will ask the user "FROM: _" on each message. BBS Menu path and barricade file Lets you set the location of menu files. This item should be left blank under most circumstances. If the area number is above 51, this item will appear as B)ARRICADE... instead of BBS PATH. In that case, the item is the fully-qualified path/file name of a barricade password list. A barricade file is a regular text file containing a list of passwords and access levels: HELLO NORMAL NIEL TWIT If a user hits a barricaded area, he/she is asked for an access code. There are three chances to get it right before Opus gets nasty and pulls the plug. In this example, if the user types HELLO, he/she is allowed into the barricaded area with the access level of NORMAL. When he/she leaves the area, the original access level is restored. Opus CBCS 1.0 -101- Operating Opus ADVANCED USERS: This is an excellent way to have assistant sysops. You can point two logical areas to the same physical subdirectory. You might make a barricaded area that has the same download path as one of your public areas. Then setup a barricade file like this: LUVVIE ASSTSYSOP By giving your assistant sysop the password LUVVIE, you can give extended capabilities in that single area. Message path Set the path to a message area. If this item is blank, it means you have no messages available for this area. (You can have files with no messages). Opus wants you to include the DRIVE designation on all paths. This is because the system will be checking on free space before allowing a user to type a message. Having the drive available makes this check easier/faster. Help path The location of Opus's help system. In most cases, this should be C:\OPUS\MISC. Download path The location of files available to users for downloading. If this item is blank, downloads are not available from this area. A file in that subdirectory called FILES.BBS normally contains a list of files available for download. If this file doesn't exist, Opus will grumble a little... but will then offer to create the file. For users who have an access code of NORMAL or below, the file must be listed in FILES.BBS or Opus will pretend that the file doesn't exist. Opus CBCS 1.0 -102- Operating Opus Upload path The subdirectory to hold files sent (uploaded) by callers. Sometimes this is the same subdirectory as the download path. If you want to censor or approve uploaded files before making them available to callers. If that's the case, the upload path should be different from the download path. Titles There are two titles: Message Area and File Area. When you select T)itles, Opus will ask whether you want to change the M)essage or the F)ile title. This is a way for you to give a name to your message and file areas. Opus will store the title you give in a file called DIR.BBS in your message and download paths. ADVANCED USERS: The file DIR.BBS cannot contain any "embedded commands" normally allowed in BBS/GBS files. Another area You can switch to any other area in the system to check or adjust the setup for the other area. There can be 100 areas... numbered 0 to 99. Before switching areas, Opus saves any changes you've made to the current area. If the area doesn't exist, the system will offer to create a new area. ADVANCED USERS: In Opus, areas don't have to be numbered consecutively. If you skip a number, all areas above the missing area number will be invisible to callers. In other words, if they do an area listing, only the consecutively numbered areas will be shown. Opus CBCS 1.0 -103- Operating Opus Quit The Q)uit command on the area maintenance menu returns you to The Sysop Section menu. Matrix This section of the documentation describes the on-line MATRIX menu. It does not attempt to describe the operation of the Matrix itself. To get to the Matrix menu, type "M" from the sysop section menu. ADVANCED USERS: There's a quick way to get to this Matrix section from the local keyboard. Type "M" when you see the "Ready" status message. Information Select I)nformation from the Matrix Menu to see a chart of all pending outbound traffic. You'll see the following items: Matrix capabilities .... a list of the current Matrix behavior attributes. Undialables ............ a list of systems Opus has had trouble calling. To get listed, there had to be an unsuccessful connection (not just a No Answer). After FIVE such connections, Opus will flag the remote system as undialable and won't try calling again. Regular bundles ........ Pre-bundled messages waiting for transmission or pickup. Continuous bundles ..... Pre-bundled messages for a system that can receive mail around the clock. Direct bundles ......... Pre-bundled messages from the oMMM program Hold bundles ........... Pre-bundled messages waiting to be picked up Opus CBCS 1.0 -104- Operating Opus Regular attaches ....... Files ready to be sent or picked up Continuous attaches .... Files for a system that can receive Matrix traffic around the clock. Direct attaches ........ Probably a list of archived echomail. Hold attaches .......... Files on-hold for pickup. Poll "POLL" means "call" in this case. Opus will ask you to type the net/node of a remote system and will call that system whether there is pending traffic or not. It will keep trying (as many as 10 times). You can consider this a "manual override" to the outbound system. Using POLL assumes you have the Matrix setup (*eg. a compiled node list and a Matrix address). Unpack Using U)npack, you can manually unpack Matrix bundles and extract/toss echomail files if you ever need to. Clear undialables Opus will remember that a system is undialable forever... until you clear that system for future calls. A system becomes undialable after Opus gets a carrier five times without successfully sending its pending Matrix traffic. Undialable systems are listed on the Matrix Information screen (discussed earlier). There are two ways to clear systems... telling Opus to try calling them. One of the ways is a housekeeping "event" (below). The other way is this menu item. Opus CBCS 1.0 -105- Operating Opus When you select C)LEAR, Opus will walk you through the list of systems. It will ask about each one: Clear 124/210 [Y/n] ? _ Type "Y" and ENTER to allow calls again. Type "N" to keep the system listed as undialable. Quit On the Matrix menu, the Q)UIT command will return you to the sysop menu. Events and behavior windows An event is something that happens at a certain time. A behavior window is the way you control the operation of the Matrix. There are 34 event "slots" available in the system. When you select E)VENTS from the sysop menu, you'll see this: OPUS EVENT MANAGER L)ist C)hange Q)uit event manager Events: _ List LISTing the events displays a chart of the active events: # Day Start TZone Duration Description -------------------------------------------- 1 All 00:00 Local 1440 min. Z/Matrix This chart shows only one event (actually a behavior window). It is in effect all week ("All" days). It starts at midnight (0:00) local time and lasts all day (1440 minutes). Opus CBCS 1.0 -106- Operating Opus Change Select C)HANGE when you want to add, modify, or delete information in one of the 34 event slots. Opus will ask you which slot you want to change: Change what event (slot) ? _ Type a number between 0 and 33. (ZERO is a number in Opus!) You will probably see something like this: S)tatus............DELETED A)nother event Q)uit The STATUS of an event changes the appearance of the screen. To put your slot in effect, type "S" and press ENTER. The screen will change: S)tatus............ENABLED K)ind..............??? D)ay...............Sun T)ime (start)......00:00 Z)one..............Local L)ength............1 !)Forced...........NO A)nother slot Q)uit Status The status of a message can be ENABLED or DELETED. Select S)tatus to flip back and forth between the two. No deleted (or disabled) event is executed. Kind The KIND of slot tell Opus what you want done during the event. There are three kinds of events: eXternal ..... tells Opus to exit at the prescribed time. When you have selected "X," a new item appears on the change menu: E)XIT CODE (see below). Opus CBCS 1.0 -107- Operating Opus Yell ......... Lets you tell Opus when it's okay to let users make noise on your computer. They have a menu item ("Yell") on the main menu. This event lets you set the hours when Yell works. Z/Matrix ..... See Z-EVENTS below. Day You can have an event happen one day or every day of the week. Time Use T)ime to set the leading edge of the event. The time should be typed using a 24 hour clock. Here are some examples: Type Meaning This ------------------ 00:00 ... midnight 01:00 ... 1:00 am 05:15 ... 5:15 am 13:42 ... 1:42 pm Zone The ZONE of an event is the TIMEZONE. You have two choices: Local time and Greenwich Mean Time. NOTE: For events to work, it is crucial that you have a TZ entry in your computer's environment. Please see the installation section for more information. Length The LENGTH of an event is the number of minutes the event is in effect. The shortest event is 1 minute. The longest event is... well... 32767 minutes... about a year and a half. Hopefully your events won't take that long. Opus CBCS 1.0 -108- Operating Opus Most of the time, eXternal events should have a duration of 1 minute. NOTE: It is your responsibility to stay outside of Opus for the duration of an external event. If you run an external event and get back to Opus before the minute has lapsed, the event will run again. Forced A FORCED event is an event which Opus refuses to miss. Let's say you have a 1 minute forced event set for 9:00 am. And... let's say you had your computer off-line all morning. When you bring the system back on-line in the afternoon, the 9:00am event will be executed. In other words, Opus will remember that it missed that 9:00am event for some reason. It will go back and pick it up before doing anything else. All FORCED events are "reset" at midnight. If you ever need to bring up the system SKIPPING forced events, you can use '-e' on the command line. This tells Opus to "reset" any forced events it may have missed. In fact, if you setup several new forced events in this Change Events section, it's a good idea to bring up Opus with the '-e' option once. Otherwise, you'll be exiting the system once for every new forced event. Exit code The E)XIT CODE option appears only when the event is declared as being eXternal (using "K)ind"). An exit code is the DOS ERRORLEVEL that the system will use. Your batch file can watch for the ERRORLEVEL you select: IF ERRORLEVEL 38 GOTO CLEANUP Refer to the DOS manual for your system for information about ERRORLEVELs and batch files. NOTE: Don't use ErrorLevel 255 or any ErrorLevel smaller than 5. Opus CBCS 1.0 -109- Operating Opus Bell duration The B)ELL DURATION only appears when the event is a Yell event. It's the number of seconds you want your computer to make noise when somebody selects Y)ell. Z-Event: Housecleaning There are two kinds of Z-events: Housecleaning and Matrix Behavior Windows. The housecleaning Z-event is used to clear out the list of systems marked as undialable by the Matrix software. To clear the undialable chart... * setup a 1 minute slot * select K)ind then type "Z" * select I)nternal kind until the screen shows "HOUSECLEANING." Typing "I" flips between Housecleaning and Matrix. * press "C" until the "C)lean Hold Area" line shows YES. * make sure the day, zone, and time are the way you want them Z-Event: Matrix behavior window Using Z-EVENTS, you can alter the behavior of Opus outbound Matrix traffic. * setup a Z-event slot * check the duration, day, zone, and starting times * select I)nternal kind until the screen shows "MATRIX." Typing "I" flips between Housecleaning and Matrix * You will see additional options: N)o outbound...................NO O)nly send local...............NO C)ont.mail only................NO M)ail only; no humans..........NO E)xits suppressed..............NO F)ile requests allowed.........NO NO OUTBOUND YES: Opus will not make any outgoing calls during the window NO: Opus will make calls Opus CBCS 1.0 -110- Operating Opus ONLY LOCAL YES: Opus will call only systems that have a zero cost field in the node list. NO: Opus will make "long distance" calls. CONT. MAIL YES: Opus will only send to systems with pending bundles and files that indicate the remote system can receive mail continuously. NO: Continuous mail is not a requirement... so Opus will send to ANY system. MAIL ONLY YES: When a human caller connects, he/she will get a message that your system is processing Matrix traffic. (National Mail Hour mode.) NO: Human callers can commingle with remote systems. (Normal mode) EXITS SUPPRESSED YES: Normal crashmail and archived mail exits are not taken. These exits are described in the sample control file (Opus.Ctl). NO: If you've setup the system to exit after inbound traffic, those exits will occur just like they were declared in your control file. FILE REQUESTS YES: Remote systems can request files from your system. NO: No file requests are accepted. Quit When you Q)UIT the event manager, you'll land back at the sysop menu. Opus CBCS 1.0 -111- Operating Opus Privs/Menus The PRIV/MENU section lets you control access to various features of the system. Select P)RIVS from the sysop menu. Opus will ask what menu you want to change: M)ain ... the main menu F)ile ... the file section menu 1-)message ... the local/echo message section menu 2-)Matrix ... the Matrix message section menu L)ORE editor ... after-edit options for the line-oriented editor C)hange ... the change user options menu S)ysop ... the sysop section menu After you've selected the menu, you'll see each item displayed on a line by itself. The current minimum access level is shown to the right. Example... G)oodbye ...TWIT This example shows the "G)oodbye" command. It is available to all callers (TWIT and up). To change the minimum access level, for a command select the command. In our example, you'd press "G" and press ENTER. You'll then see a chart of the available access levels. Just pick one from the chart. ADVANCED USERS: For zippier action, you can "stack" commands. Press ENTER by itself to save your changes and return to the PRIV menu. Opus CBCS 1.0 -112- Operating Opus Outside You can run an external program or drop to DOS from the sysop section using the O)utside command. Please refer to the sample control file for information on how to setup this command. NOTE: In the control file, this command is called the "ZERO COMMAND" because "0" is the key that used to be used for this item. Embedded Commands You can lead a full and meaningful life without using any of these control codes. In fact, misusing them can probably lead to a lot of grief. There is nothing here for the novice. If you are not intimately familiar with Opus and communication systems, please wait 'till later to use control codes. Most of the control codes assume you know what you are doing. Because the GBS/BBS files are prepared with a word processor or text editor (i.e, not using any Opus software), there is no way for Opus to check your work. You should review any files you create using Opus's KEYBOARD MODE before trusting the file to an on-line situation. The Control-O commands (below) can be particularly lethal if you aren't careful. An overabundance of control codes in a BBS/GBS file can make a totally unmaintainable file. You can build these files using any text editor that can insert control codes into files, but I would consider such a method the "Assembly Language of BBS/GBS Files". A handy Opus sysop utility would be some sort of program (e.g., WYSIWYG BBS/GBS editor) to make the result of these codes visible during development. At this writing, no such utility exists. [soapbox on] It's very possible, using these commands, to turn a perfectly good system into one full of gimcracks (useless junk). An Opus sysop has an order of magnitude more power over his/her system than does a Fido<tm> v11 sysop. If you take that control, you must also share the responsibility. I think it's great to add a little spice to a system, but the average user doesn't call to see his/her screen wiggle. These commands are intended to give the experienced sysop lots of versatility. They are very easy to overdo! Opus CBCS 1.0 -113- Operating Opus Also... remember that if you use the MS-DOS graphics characters in a BBS/GBS file, you are going to make non-MS-DOS screens look funny because they won't know how to display the characters. There is absolutely nothing "non-standard" in Opus itself. If you choose to add such features, you also need to be prepared to answer questions and/or complaints about them. [soapbox off] These control codes can be inserted into any .BBS or .GBS file. The only exception is DIR.BBS ... which must be a plain text file. The basics ^A ... "Press ENTER to continue: " ^B ... disable ^C/^K aborting ^C ... enable ^C/^K aborting ^D ... Mark that it's a good time for a "MORE?" ^E ... Turn auto-More ON (default) ^F ... COMBINATION COMMAND (see below) ^G ... Ring the caller's bell ^H ... Backspace ^I ... Tab ^J ... Line feed ^K ... Turn auto-More OFF ^L ... Clear screen ^M ... Carriage return ^N ... [ reserved ] ^O ... COMBINATION COMMAND (see below) ^P ... COMBINATION COMMAND (see below) ^Q ... Used for XON/XOFF. Never use this. ^R ... [ reserved ] ^S ... Used for XON/XOFF. Never use this. ^T ... [ reserved ] ^U ... [ reserved ] ^V ... video (oAnsi) ^W ... [ reserved ] ^X ... [ reserved ] ^Y ... [ reserved ] ^Z ... MS-DOS end of file marker. Never use this. Opus CBCS 1.0 -114- Operating Opus Data display NOTE: Both command characters in this section are CONTROL characters. The `^' symbol means `control.' For example, `^F' represents CONTROL-F. ^F^A ... quote of the moment ^F^B ... user's name ^F^C ... user's city/state ^F^D ... current date ^F^E ... total number of calls user has made to system expressed as an ORDINAL number (*eg. `1st', `2d', etc) ^F^F ... user's first name ^F^G ... dramatic one-second pause ^F^K ... total minutes on-line in the last 24-hours, including the time for the current call ^F^L ... length of the current call so far (in minutes) ^F^N ... control-niel (disconnect) ^F^O ... number of minutes remaining for this call ^F^P ... written-out date/time when the user has to be off the system. NOTE: This uses a built-in Lattice-C routine which appends the line with a <CR/LF>. You should consider using ^F^P at the END of a line with no punctuation ... until Prof.Norton and I can get in and change a couple of things. ^F^Q ... number of calls to system to date (ORDINAL NUMBER) ^F^R ... NET downloads today (download minus upload). If uploads are greater than downloads, this number will be negative. ^F^T ... current time ^F^U ... on a questionnaire, all answers are required ^F^V ... on a questionnaire, all answers are optional ^F^W ... total user uploads ^F^X ... total user downloads ^F^Y ... upload:download ratio NOTE: Several ^F commands deal with the amount of time a user has remaining. Until the user is totally through the logon procedure, he/she will have about 10 minutes. The use of these commands prior to the first MAIN MENU may produce unexpected results. Opus CBCS 1.0 -115- Operating Opus Questionnaires, surveys, order forms NOTE: The second character of the commands in this section is a REGULAR ("printable") character ... NOT a control character. HINT: Calm down a little, there are samples at the end of this file. ^OMd ... store the last `^OR' response to the answer file. (See `^OR' below). `d' is is a description of the item which is NOT displayed. The description is stored in the answer file. Also, see the examples at the end of this file for more information. ^ONd ... let the user type a line and store it in the user file. This roughly corresponds to the Fido<tm> "/" command in questionnaires. `d' is for a description of the entry in the answer file. ^OOf ... open an answer file. `F' is a fully-qualified file name including path, node, and extension. ^OP ... post user information to the answer file Flow and user interaction NOTE: The second character of the commands in this section is a REGULAR ("printable") character ... NOT a control character. +-------------------------------------------+ | "Remember-- no matter where | | you go, there you are." | | --Buckaroo Banzai | | | +-------------------------------------------+ ^OCp ... call MS-DOS with the command "p". This is an embedded "O)utside" command. "P" is some command, possibly the name of a program or batch file. It is sent to MS-DOS (via Command.Com) without modification. ^ODp ... set subdirectory for future "chain" type bbs calls. "p" is the path to BBS files called from the current BBS file. ^OFb ... "On exit". Declare the name of a GBS/BBS file to be transmitted if, for any reason, the current file is terminated. Opus CBCS 1.0 -116- Operating Opus ^OQ ... quit the file immediately ^ORv ... read menu. `V' is a sequence of characters ... a list of the valid responses. Opus considers all of the characters between the `R' and the first character less than or equal to the space character to be part of the list. In other words, you terminate the list with a space, tab, end of line, or any other control character. Refer to an "ASCII CHART" for help in finding what characters are "below" the space. Opus takes care of upper/*lowercase conversion for you. It is your responsibility to handle any user prompts: there is no display associated with this command. "Command stacking" is fully supported. If the user types an unrecognized character, Opus will ask him/her to try again. ^OS ... show another file. The REST of the current line is considered the name of a BBS/GBS file. Do *not* include the file's extension. You can include a drive and path. Most settings (*eg Color, Auto-More) are maintained across file boundaries. If the file you specify doesn't exist, the entire display sequence is ended and the user is returned to Opus. ^OT ... top of file (dangerous: can produce an "endless loop"). Useful only for handling "fall-through" menu situations and (with ^B set) for handling niels. (ah-hem) ^OUc ... user response. "C" is a single character. It is the way to process information from the read menu (^OR) command. If the user's most recent response was not the value you give for `c', the REST OF THE CURRENT LINE is ignored. ^OVn ... "goto." This is a dangerous command that is primarily intended for use by automated programs that generate and/or maintain BBS files. The "n" is an ASCII representation of a 32-bit (long) integer. It is an absolute location (counting from the beginning) in the file. In other words, "^OV0" would send Opus to the beginning of the .BBS file. The line "^OV1234" would tell Opus to begin execution of the .BBS file from the 1234th byte of the file. The offsets are 0-based. Privilege control NOTE: The second character of the commands in this section is a REGULAR ("printable") character ... NOT a control character. Opus CBCS 1.0 -117- Operating Opus Dealing with the rest of the file... ^PD ... Below Disgraced don't see rest of file ^PN ... Below Normal don't see rest of file ^PP ... Below Privil (or Privel) don't see rest of file ^PE ... Below Extra don't see rest of file ^PA ... Below Assistant sysop don't see rest of file ^PS ... Below Sysop don't see rest of file Commands dealing with the rest of the current line... ^PLD ... Below Disgraced don't see rest of line ^PLN ... Below Normal don't see rest of line ^PLP ... Below Privil (or Privel) don't see rest of line ^PLE ... Below Extra don't see rest of line ^PLA ... Below Assistant sysop don't see rest of line ^PLS ... Below Sysop don't see rest of line FILES.BBS Commands @ ... in column one, stops display for those under AsstSysop. This is for Fido<tm> compatibility only. You should not count on this remaining after Version Zero. Use a ^P command instead. - ... column one only. turns on WHITE. The display will remain white until the next file name. FIDO<tm>-Compatible questionnaire commands COMMANDS Gone -- as we warned in the 0.0 documentation. All of the functionality from the Fido commands is available with ^O commands. Opus CBCS 1.0 -118- Operating Opus Example 1 CONTENTS OF THE EXAMPLE 1 FILE: Please select one of these: H)elp on using the system T)rojan horse program alert E)quipment used on-line Q)uit Select: ^ORhteq ^L ^OUh^OSc:\opus\morehelp ^OUt^OSc:\opus\trojans ^OUq^Oq We use an AT computer with a 30 meg Seagate disk drive. The modem is a USR Courier 2400. There is 640k system memory with 3 megabytes of extended memory which is used as a RAM disk. ^OT NOTES FOR EXAMPLE 1: A short menu system for multiple bulletins. First, the menu is displayed. Then, after "Select: ", Opus will wait for the caller to type `H', `T', or `A'. For aesthetics, we clear the screen after the menu response (^L). Then.... if the caller typed `H', we will display the file MOREHELP. If it's `T', the caller will see TROJANS. If the caller typed `Q', we will exit the file display and return to Opus. The only unaccounted-for menu response is `E' ... which is taken care of by the material at the end. In other words, if the user gets to the part beginning with "We use an...", he/she must have typed an `E'. It's the "fall- through" case here. Because Opus doesn't have to change to another file, the fall-through will always be the quickest. Finally, at the end of the file, we tell Opus to recycle and display the menu again (^OT). Opus CBCS 1.0 -119- Operating Opus Example 2 CONTENTS OF THE EXAMPLE 2 FILE: Welcome to the board, ^F^B. ^OOc:\opus\newusers.txt ^OP What is your occupation? ^ONoccupation Please find your favorite color ... B)lue R)ed M)agenta L)ilac Y)ellow P)uce Type the first letter of your choice: ^ORbrmlyp ^OMchoice ^OUbBlue! really? Wow, that's my favorite color, too! Thanks for taking the time to fill out this questionnaire. NOTES FOR EXAMPLE 2: A short survey. First we do a welcome that includes the user's name (^F^B). Then we setup an answer file called C:\OPUS\NEWUSERS.TXT. Any responses will be put into this file. Note that the answer file stays open across files ... should you swap files using ^OS. The first item we put into the answer file is the user's name (^OP). It is NOT ever necessary to ask a user "What is your name"... not even a new user. It is easier on the system and the caller to use the ^OP command rather than being redundant. The first question deals with the user's occupation. The display would look like this: What is your occupation? _ Whether an answer is required depends on whether you have used the ^F^U or ^F^V commands. If the caller typed "accountant" then your answer file would contain this line: occupation: accountant The description "occupation" was part of the ^ON command itself. Opus CBCS 1.0 -120- Operating Opus The next piece of business is a multiple choice question. It works exactly like the MENU in example #1 above. The addition is `^OMchoice' to store the user's response in the answer file. For example, if the user selected RED, the answer file would look like this: choice: R Note that if the caller likes BLUE, Opus will get all excited. See the `^OU' statement. We use this line for two reasons: 1)to show that you can get exceedingly (excruciatingly) clever; and 2)you can combine almost any ^O commands. You can have more than one answer file. Every time you use ^OO, the current answer file is closed and the new one opened or created. One side effect involves opening the same file... not advised for normal operation... but that is one way to force Opus physically to write to disk any responses it has buffered. Opus CBCS 1.0 -121- Operating Opus For more information on Opus There are two ways to find out more about the way Opus works and to get questions answered. If you are having problems with Opus, contact one of the InfoNodes. They can be reached at: System name Phone number Matrix Notes ----------- ------------ ------ ----- OPUSinfo Here (214) 991-3381 1/113 9600 bps OPUSinfo There (415) 672-2504 161/1 2400 bps These are for questions involving specific problems. They can give you answers to some of the most commonly asked questions. Other help nodes are: System name Phone number Matrix Notes ----------- ------------ ------ ------ OPUSinfo Pursuit 415-621-5206 ----- via PC PURSUIT OPUSarchive 302-764-7522 150/1 tech reference Still more nodes where you can route specific suggestions or requests: Complaints ............. NUL: Documentation .......... 133/12 DEC Rainbow ............ 141/491 FOSSIL echo area ....... 132/101 oMMM operation ......... 132/101 OpusNode information ... 137/42 Matrix dialing scripts.. 14/614 Meadow echo area ....... 124/110 Net_Dev echo area ...... 132/101 Suggestions ............ The Meadow Telebit Trailblazer .... 141/491 USR HST ................ 115/500 For general discussions about the usage of Opus, you should consider subscribing to the Opus sysop EchoMail area, called MEADOW. Any of the distribution nodes can refer you to a tie-in point for this area. If all else fails, contact Jon Sabol at 124/210 for information pertaining to MEADOW EchoMail connections. Opus CBCS 1.0 -122- Opus Information MEADOW carries the same copyright as Opus. You are required to act in a friendly and lawful manner if you participate. We are trying desperately to keep a casual and constructive atmosphere in the Opus area. If that is not your intent, please do not subscribe to the conference. If you wish to discuss technical aspects of the programs, you are wholeheartedly welcome to join!!! Opus CBCS 1.0 -123- Opus Information Appendix A - Cyberpunk? +-----------------------------------------------+ | | | Cyberpunk comes from the realm where the | | computer hacker and the rocker overlap, a | | cultural Petri dish where writhing gene | | lines splice. Some find the results bizarre, | | even monstrous; for others this integration | | is a powerful source of hope. | | | | - Bruce Sterling | | | +-----------------------------------------------+ This has nothing to do with Opus, exactly, but because I called The Matrix "the world's first CyberPunk BBS Network" I'd better explain the term. CyberPunk is a kind of science fiction. Characters in such works have been described in several ways. Here are a couple: * Low-budget high tech * Miami Vice with lasers * Ray-gun gothic The street people in such books are normally the techies. It can conjure up images of that broken-down freighter in the original Star Wars if you aren't careful. The TV show MAX HEADROOM is CyberPunk. One repeating theme is this: surrounded by computers and equipped with the knowledge of how to use them, Cyberpunk characters often struggle to maintain a sense of humanity. If there is to be any kind of struggle, that particular one sounds more worthy of my time than others. Opus CBCS 1.0 -124- Appendix A Finally, a short conversation from Gibson's "Johnny "Mnemonic.".. "Who's Lo Tek?" "Not us, boss." Lo Tek is just a gang in the book, of course. But it's a term you may run across from time to time when you hook into The Matrix: The World's First CyberPunk BBS Network. Opus CBCS 1.0 -125- Appendix A Appendix B - Opus and support file list: The following filenames are hard-coded in Opus, and must not be changed: CHGPRIV BBS - C)hange menu DIR BBS - Area header in each area. FILES BBS - File listing in each file area. EDITPRIV BBS - Message editor menu FILEPRIV BBS - File menu MAILPRIV BBS - Matrix menu MAINPRIV BBS - Main menu MSGPRIV BBS - Message menu SYSPRIV BBS - Sysop menu SYSTEM BBS - Main System file SYSTEM1 BBS - Message / File area 1 SYSTEM2 BBS - Message / File area 2 (etc......) LASTUSER XXX - Last user to go outside (XXX=task$) OPUSCHAT XXX - Chat buffer (XXX=task$) F1 BBS \ F2 BBS \ F3 BBS \ F4 BBS \ F5 BBS \ Function key display files. F6 BBS / These can be .GBS for graphics F7 BBS / F8 BBS / F9 BBS / F10 BBS / WHY_ANSI BBS - help screen for the (ANSI y/n) question WHY_FB BBS - help screen for the logoff prompt. WHY_HU BBS - Help for the G)oodbye command WHY_PVT BBS - help for the (Private?) Message prompt C BBS - C)hange help screen FILES BBS - File area help screen MAIL BBS - Matrix help screen MAIN BBS - Main menu help screen MSG BBS - Message area help screen OPUS EXE - Opus itself Opus CBCS 1.0 -126- Appendix B The following files MAY be changed in Opus, but be aware some external (third-party) utilities may expect them to have their original names: SCHED BBS - Scheduler record OPUSGRAF EXE - Displays settings in Control file OPUS_CTL EXE - Control file compiler ANSWER BBS - Q)uestionnaire answer file USER BBS - User records BULLETIN BBS - System Bulletin WELCOME1 BBS - Initial welcome screen WELCOME2 BBS - Second welcome screen EDTORIAL BBS - System Editorial NEWUSER1 BBS - Initial New user screen NEWUSER2 BBS - Second new user screen QNEWUSER BBS - Auto questionnaire for new users QUESTION BBS - Q)uestionnaire file QUOTES BBS - System Quotes These files may be renamed with impunity: OPUS CTL - Opus Control File OPUS LOG - Sysop Log OPUS PRM - Opus Parameter file (compiled OPUS.CTL) EDITOR BBS - Help screen for the Editor INQUIRE BBS - help screen for the Inquire command LOCATE BBS - help screen for the Locate command BYEBYE BBS - Logoff screen CONTENTS BBS - help screen for the Contents command DAYLIMIT BBS - For users whose daily time is up FILEAREA BBS - List of file areas. LEAVING BBS - Show to users before they go outside MSGAREA BBS - list of message areas RETURN BBS - Shown to users returning from Outside REP_EDIT BBS - Help for REPLACE on the Editor menu ROOKIE BBS - Welcome2 screen for users <7 calls. TIMEWARN BBS - Time limit warning TOOSLOW BBS - Your modem is too slow XFERBAUD BBS - Screen for users too slow to up/download FILE LOCATIONS File is maintained by... s ... sysop or some external utility o ... Opus b ... both sysop and Opus Opus CBCS 1.0 -127- Appendix B FILE NAME v NOTES Barricade (password) lists..s default dir. or as specified (in System?.Bbs field) DIR.BBS.....................s each message and file area subdirectory FILES.BBS...................b each file area subdirectory FILES.BAK...................o each file area subdirectory (created by Opus when it changes Files.Bbs) XFERINFO.xxx................o internal temp file (default drive/directory)* SYSTEM?.BBS.................b "Path system" in the CTL file LASTREAD....................o each message area subdirectory *.MSG.......................o each message area subdirectory. Note that all message areas should be on the same physical drive. _TMP_.$$$...................o file transfer temp file (internal) BUNDLE......................o Matrix session temp file (internal) NODELIST.SYS................s "Path NetInfo" in the CTL file ECHO.CTL....................s "Path NetInfo" in the CTL file ECHOTOSS.LOG................b default drive/directory KILLDUPE.DAT................o each echomail message area OPUSCHAT.xxx................o default drive/directory* All Matrix dialing scripts..s "Path NetInfo" in the CTL file BADARC.???..................o Inbound file area (an LZW Matrix file that could not be decompressed by ARCE). BAD_BNDL.???................o Default drive/directory (a Matrix message bundle that Opus couldn't unpack). Opus CBCS 1.0 -128- Appendix B Appendix C - Miscellaneous reference stuff Multitasker notes Matrix processing on more than one task isn't recommended for v1.00. Although you can accept inbound traffic on all partitions, you should restrict processing (scan/arc'ing/etc) to a single partition. There is no protection against collisions in the internal echomail scanner or in such external programs as ARCA and ARCE. DoubleDOS Notes Some folks consider DoubleDOS to be an amazing piece of software. That may be true, but it tries to make PC type computers do something that the machine wasn't designed to do: multi-task. If you plan to use DoubleDOS, here are some things to keep in mind..... * Set the "Multitasker DoubleDOS" option in your Opus control file. Opus will stall if you have this switch set and run it without DoubleDOS. * Don't use any of the COM definitions in DDCONFIG.SYS. * At high speeds, DoubleDOS loses interrupts on a context switch. That means if you are running 2400 baud or above, flipping from one partition to the other may cause the system to lose one or more characters. This can sometimes be critical during such things as file transfers. * At high speeds, some non-Opus programs cause DoubleDOS to do so much work that it loses interrupts. Here's one thing that doesn't seem to work on a 6mHz AT: running Opus in the foreground with a file transfer going at 9600 baud and a steady modem-to-computer speed of 19.2kb with PLINK running in the background. The PLINK program seems to keep DoubleDOS so busy that the system gets CRC errors (on an error-free connection!). Opus CBCS 1.0 -129- Appendix C * If you run more than one phone line, you should have Matrix processing going on only one partition. This doesn't mean you can't setup both tasks to accept Matrix traffic, but scanning/arc'ing/etc on both partitions on a busy system can cause some fairly colorful collisions. Future versions of Opus will (hopefully) address this problem. You and Opus and DoubleDOS can establish a happy and meaningful relationship if you keep these things in mind. You just need to know that running a multi-tasker on a single-task machine is more of an art than a science. Modem notes USR Courier The "X" setting in the init string for a USR Courier must be "X4" or less. If you use "X6," the modem will incorrectly report a VOICE connection when it tries to negotiate a baud rate with a Telebit TrailBlazer modem. Telebit Trailblazer The TeleBit TrailBlazer is a powerful piece of machinery. Because of that, you will do better if you have a powerful computer. Although the TrailBlazer has been successfully run on slow MS-DOS machines (like the DEC RainBow), it seems almost like a waste of a good modem to run it on anything less than an AT. The fewer resident programs you have, the better. That's because the computer needs all the horsepower it can get just to keep up with this modem. With a fairly clear phone line, we've seen ZModem netmail connections with file transfer rates of 12kb, but those speeds require two fast computers driving the modem. You can't really expect file transfer throughputs above 8000 baud with a 4.77mHz computer. Opus CBCS 1.0 -130- Appendix C Registers Here is a sample register chart from an Opus 1 system. It was generated using the TrailBlazer's "AT&N" command: E1 F1 M1 Q0 T V1 X1 Version Q2.19CM6-025 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006 S10=007 S11=070 S12=050 S45=000 S48=000 S49=000 S50=000 S51=005 S52=001 S53=001 S54=000 S55=000 S56=017 S57=019 S58=002 S59=000 S60=000 S61=045 S62=003 S63=001 S64=000 S100=000 S101=000 S120=000 S121=000 S122=001 This setup includes a locked computer-to-modem interface speed of 19.2kb. Initialization The initialization sequence in the sample Opus control file . . . ~|AT&FS0=1S51=5S52=1S53=1S7=60S58=2S9=1S66=1S68=2Q0E0H0M0V1| . . . is a good deal more intense than it really needs to be. It is a fairly safe and conservative approach. Some use the "&W" command to write the values to the modem's non-volitile memory. If you do that, you may be able to get by with nothing more than "ATZ" in Opus itself. Opus Control File In addition to the initialization sequence, you should use the following items: Modem STEADY % -- lock the interface speed Mask CARRIER 128 % -- carrier detect mask Mask HANDSHAKING XON % -- use xon/xoff Mask HANDSHAKING CTS % -- use cts/rts Known Problems The TrailBlazer proms in our test machine had two problems: * If RTS is toggled too quickly, the modem doesn't realize it's been changed. The folks at TeleBit say this is fixed in more recent PROM versions. Opus CBCS 1.0 -131- Appendix C * When there is a hard collision (eg. Opus trying to send the init string at the same time somebody is trying to call), the TrailBlazer drops to a 9600 interface speed. Apparently it reloads the factory setting instead of the non-volitile register settings. Fortunately this doesn't happen often. When it does, your only recourse is the switch on the modem. Hayes V-Series Regrettably, Opus cannot be expected to operate correctly with a Hayes "V-Series" modem. Here's why: Hayes has redefined the set of response strings. Instead of a simple CONNECT <baud> there's now a connect message followed by a line of protocol information, followed by a "CARRIER <baud>" line. Also, it's impossible to lock the V-Series interface speed. Although connections are possible or likely, NONE OF THE BAUD-RATE SENSITIVE TIMINGS AND LIMITS WILL WORK. The connection responses would look something like this: CARRIER <baud> [some line about handshaking is here] CONNECT <baud> That may not be exact, but it illustrates the problem. The V- Series hasn't just redefined the CONTENT of the connection sequence, it has redefined the STRUCTURE of the whole thing. The point is that it would take considerable code to support the V-Series with its sometimes-locked interface baud rate. We would have two kinds of modems: the V-Series and the rest of the world. Until the V-series gains wider acceptance, there's no reason to use up code space on every body's disk just to support it. (This is subject to change, however.) Like it says in the specs, Opus requires a "Hayes-compatible" modem, and the V-Series certainly can't be put into that category. <sigh> July 13, 1987 Opus CBCS 1.0 -132- Appendix C